Bad press again...

classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Steve Wray:

> Another example is fwbuilder which *silently* fails to overwrite its
> generated script at compile time if the user doesn't have write
> permissions on the existing script.

Most bugs in security tools are security bugs.  We have to draw a line
somewhere, otherwise "stable" becomes meaningless.

> I view this as a security problem because what if you *think* you've
> made changes to your firewall and are now protected only... you arn't
> and the firewall hasn't been updated?
>
> Is that enough of a security problem for the fix to get into stable?

The underlying problem seems to be that fwbuilder does not provide
means to test a configuration after it has been applied to the system.
Such tests would catch a more general class of problems, and not just
some isolated file system problem.

My hunch is that the fwbuilder bug is just a normal bug which should
be fixed, but does not trigger the security update procedures.  The
shorewall bug falls on the side of the line, it is a security bug.

To some extent, it is possible to formalize the underlying decision
process.  However, with the current state of the technology we use, it
is very hard to properly define what a security vulnerability is.
Most definitions (e.g. "deviations from a documented security policy")
do not cover issues which everyone agrees are security defects
(because the vendor's official security policy requires that the
product is only connected over the network to machines within the same
administration domain and exposed to cooperative users only, for
example).  However, it's certainly helpful to have some guidelines.
But all this only makes sense if the existing security team agrees.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Michael Stone-2
* Michael Stone:

> On Mon, Aug 29, 2005 at 11:44:59PM +0200, Florian Weimer wrote:
>>IMHO, Debian should publish at least a DSA that explains this
>>discrepancy, especially if the package maintainer also thinks that
>>it's necessary.
>
> Thank you for your input. Would anyone else like to register their
> opinion? BTW, did you miss the part where I insinuated that the security
> team is looking for some clarification? There's not much point in
> issuing an advisory before that, is there?

I think this part of the diff is pretty instructive, together with
upstream's explanation:

  if [ -n "$MACLIST_TTL" ]; then
     chain1=$(macrecent_target $interface)
     createchain $chain1 no
-    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j $chain1
-    run_iptables -A $chain1 -m recent --update                        --name $chain -j ACCEPT
-    run_iptables -A $chain1 -m recent --set                           --name $chain -j ACCEPT
+    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j RETURN
+    run_iptables -A $chain                                                          -j $chain1
+    run_iptables -A $chain  -m recent --update                        --name $chain -j RETURN
+    run_iptables -A $chain  -m recent --set                           --name $chain
  fi

If I read the iptables manual page correctly, the --update and --set
rules jump to the ACCPEPT target, letting through the packet.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Steve Wray
In reply to this post by Florian Weimer
Florian Weimer wrote:

> * Steve Wray:
>
>
>>Another example is fwbuilder which *silently* fails to overwrite its
>>generated script at compile time if the user doesn't have write
>>permissions on the existing script.
>
>
> Most bugs in security tools are security bugs.  We have to draw a line
> somewhere, otherwise "stable" becomes meaningless.

Actually, having followed the mozilla/firefox discussion and various
other thread on this list, I am inclined to believe that the concept of
a "stable" distribution in the modern internet/open source environment
is already meaningless.

>>I view this as a security problem because what if you *think* you've
>>made changes to your firewall and are now protected only... you arn't
>>and the firewall hasn't been updated?
>>
>>Is that enough of a security problem for the fix to get into stable?
>
>
> The underlying problem seems to be that fwbuilder does not provide
> means to test a configuration after it has been applied to the system.
> Such tests would catch a more general class of problems, and not just
> some isolated file system problem.

Not quite.

When the fwbuilder application tries to write to the file, it fails.
This exception doesn't appear to be handled by anything at all and hence
the silent failure to write to the file.

The issue of actually testing firewall configurations is a whole 'nother
problem.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Steve Wray:

>>>I view this as a security problem because what if you *think* you've
>>>made changes to your firewall and are now protected only... you arn't
>>>and the firewall hasn't been updated?
>>>
>>>Is that enough of a security problem for the fix to get into stable?
>>
>>
>> The underlying problem seems to be that fwbuilder does not provide
>> means to test a configuration after it has been applied to the system.
>> Such tests would catch a more general class of problems, and not just
>> some isolated file system problem.
>
> Not quite.
>
> When the fwbuilder application tries to write to the file, it fails.
> This exception doesn't appear to be handled by anything at all and hence
> the silent failure to write to the file.
>
> The issue of actually testing firewall configurations is a whole 'nother
> problem.

But you agree that automated tests of the configuration, after it has
been written and applied, would detect such a problem (if there are
proper test cases, of course)?

I'm NOT saying that the bug shouldn't be fixed.  What I want to say
that the mere occurrence of such a bug is a symptom of a larger
problem in the software.  If we start labeling such symptoms as
security bugs, we can probably issue five DSAs a week for ordinary
bugs in software which is somewhat security-related.  ("GnuPG crashes,
and users might skip verification of a signature on an important
document, putting them at risk" -- is this really a security bug?)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Steve Wray
Florian Weimer wrote:
> * Steve Wray:
>
>
>>>>I view this as a security problem because what if you *think* you've
>>>>made changes to your firewall and are now protected only... you arn't
>>>>and the firewall hasn't been updated?
>>>>
>>>>Is that enough of a security problem for the fix to get into stable?
[snip]

>>When the fwbuilder application tries to write to the file, it fails.
>>This exception doesn't appear to be handled by anything at all and hence
>>the silent failure to write to the file.
>>
>>The issue of actually testing firewall configurations is a whole 'nother
>>problem.
>
>
> But you agree that automated tests of the configuration, after it has
> been written and applied, would detect such a problem (if there are
> proper test cases, of course)?

Regression testing of firewall rules would have to be the 'holy grail'
of the work we do here, where there are approximately one bazillion
firewalls to manage, with regular changes to production systems.

It'd need some serious AI programming though and probably some sort of
netfilter simulator. It shouldn't be too hard to implement in an
appropriate language. Prolog or one of the 'constraint programming'
languages perhaps. But this, while fascinating, is getting way off topic
:)

> I'm NOT saying that the bug shouldn't be fixed.  What I want to say
> that the mere occurrence of such a bug is a symptom of a larger
> problem in the software.  If we start labeling such symptoms as
> security bugs, we can probably issue five DSAs a week for ordinary
> bugs in software which is somewhat security-related.  ("GnuPG crashes,
> and users might skip verification of a signature on an important
> document, putting them at risk" -- is this really a security bug?)

This is very true and pretty well what I'm getting at. I don't believe
that there can be any hard and fast rules as to what counts as enough of
a bug to count as a security bug. Its down to people making decisions.

In the end, I imagine that a lot of production sites out there are
*having* to move to debian 'backports'. They certainly were for woody...

Now is *that* good for anyone concerned? I don't believe that it is; the
backport packages probably don't get anywhere near the QA that packages
that actually go into 'stable' get.

Sometimes I get the feeling that the end user must choose between
reliability and security which is, in truth, a total oxymoron.

I just get the feeling that things today move too fast to hold any
distribution to a very strict interpretation of 'stable'.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Michael Stone-2
In reply to this post by Florian Weimer
On Tue, Aug 30, 2005 at 12:17:22AM +0200, Florian Weimer wrote:
>I think this part of the diff is pretty instructive, together with
>upstream's explanation:

Frankly, no, it's not.

> if [ -n "$MACLIST_TTL" ]; then
>    chain1=$(macrecent_target $interface)
>    createchain $chain1 no
>-    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j $chain1
>-    run_iptables -A $chain1 -m recent --update                        --name $chain -j ACCEPT
>-    run_iptables -A $chain1 -m recent --set                           --name $chain -j ACCEPT
>+    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j RETURN
>+    run_iptables -A $chain                                                          -j $chain1
>+    run_iptables -A $chain  -m recent --update                        --name $chain -j RETURN
>+    run_iptables -A $chain  -m recent --set                           --name $chain
> fi

I still have no idea what "chain1=$(macrecent_target $interface)" means.
I'm not sure why there's both an "update" and an "rcheck"--the man page
says they're equivalent, except that update has an additional side
effect. But if that's the case, why put the update in at all, since
there's a return after the rcheck and you'll never get to the update.
Presumably that has something to do with the mysterious chain1.  If we
pull up the full source we find that macrecent_target
is defined as
macrecent_target() # $1 - interface
{
    [ -n "$MACLIST_TTL" ] && echo $(chain_base $1)_rec || echo RETURN
}
and we enter a maze of twisty functions, all alike. (Side note, this is
why I create my firewall rules by hand :-)  At any rate, this is why we
have package maintainers, who are presumably conversant with the code,
and with whom the security team can work to understand the issues at
hand.

I already outlined some of the questions and their rationales, which
your answer doesn't address (questions about interface and expectations
and possible unintended uses). There are some other things that are
quite vague in the original advisory. It says that if "a client is
positively identified through its MAC address, it bypasses all other
policies/rules in place, thus gaining access to all open services on the
firewall". What is "a client"? If you put in your router's mac address,
is any non-local ip granted access to anything?  The answer to these
questions isn't in a 4 line diff, the answer lies in a conversation with
someone who has spent time with the code and has actually used the
program. (And FWIW, I don't think that this list is the right place for
that conversation; if you have something else to add, send it to the BTS
and CC the security team.) Yeah, a careful look at the code could
probably answer these questions, but there are a lot of issues on the
queue...

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Antti-Juhani Kaijanaho-2
In reply to this post by Frans Pop
Frans Pop wrote:

> On Monday 29 August 2005 22:23, Florian Weimer wrote:
>
>>I've obtained permission from tbm to quote the message reproduced
>>below in public.  This should make it clear that the intent was to
>>delegate: "Nach [URL] hat debian-admin klar die Authorit├Ąt" --
>>"according to [URL], debian-admin clearly has authority", and
>>debian-admin was only listed in the referenced web page.  If the DPL
>>felt that even that was enough to express delegation, mentioning the
>>security team in the list message itself should make things even more
>>clear.
>
> Does that mean everybody listed in the w.d.o/intro/organization pages is
> automatically a delegate in the formal sense?
The [URL] in the above quoted sentence was the -announce post, not the
organization page.

--
Antti-Juhani


signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Frans Pop
On Tuesday 30 August 2005 10:34, Antti-Juhani Kaijanaho wrote:

> Frans Pop wrote:
> > On Monday 29 August 2005 22:23, Florian Weimer wrote:
> >>I've obtained permission from tbm to quote the message reproduced
> >>below in public.  This should make it clear that the intent was to
> >>delegate: "Nach [URL] hat debian-admin klar die Authorit├Ąt" --
> >>"according to [URL], debian-admin clearly has authority", and
> >>debian-admin was only listed in the referenced web page.  If the DPL
> >>felt that even that was enough to express delegation, mentioning the
> >>security team in the list message itself should make things even more
> >>clear.
> >
> > Does that mean everybody listed in the w.d.o/intro/organization pages
> > is automatically a delegate in the formal sense?
>
> The [URL] in the above quoted sentence was the -announce post, not the
> organization page.
No, the key of his argument is in "and debian-admin was only listed in the
referenced web page" which was the organization page.

The weird thing is that that German mail was not about the security team
at all, but about the debian-admin team, and the status of all other
teams in existence is being extrapolated from that.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Petter Reinholdtsen
In reply to this post by Frans Pop

[Frans Pop]
> IMO the status of the security team is not changed by that mail: if
> it was delegated before that time, it still is, and similar if it
> was not.

Personally, I only find it reasonable that all groups in Debian with
special privileges within the Debian community are delegates.  It
avoid the danger of small kings of the hill protecting their turf from
contributions and improvements.

Here at the university, I've seen way to many professors and system
administrators trying their best to avoid improvements and change by
protecting their turf in innovative ways, to believe that Debian will
be protected from the same problem.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Paul Gear
In reply to this post by Florian Weimer
Florian Weimer wrote:

> ...
>>If we're going to have another crack at it, then, what track should we
>>take?  Reopen the bug as Florian suggested,
> ...
>>email the security team, just keep pestering Joey?
>
>
> IMHO, the first step would be to convince the shorewall maintainer
> that a security update for stable needed. [*] Then someone needs to
> prepare an update (preferably the maintainer or someone else who is
> familiar with the software).  This is slightly complicated by the
> unfortunate fact that the patch in the errate of 2.2.5 does not apply
> cleanly to the 2.2.3 version.
The maintainer is not the problem.  Lorenzo has prepared 2.2.3-2 for
sarge [1] and has tested the before and after situations and found that
the bug is fixed.  The problem is no response from Martin Schulze.

[1] http://idea.sec.dico.unimi.it/~lorenzo/tmp/

--
Paul
<http://paulgear.webhop.net>
--
Did you know?  Using accepted quoting conventions makes
your email easier to understand.  Learn how at
<http://www.netmeister.org/news/learn2quote.html>.

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Paul Gear
In reply to this post by Florian Weimer
Florian Weimer wrote:
> ...
> It seems that shorewall generates an ACL that ACCEPTs all traffic once
> a MAC rule matches.  Further rules are not considered.  The
> explanations in version 2.2.3 seem to indicate that this was the
> intended behavior, but its implications surprised upstream, and a
> corrected version was released.

That's not an accurate summary of the Shorewall team's stance.  It is a
simple bug.  When someone uses MAC filtering in their firewall rules, it
was always intended that a system which passed the MAC filter still be
subject to the other rules (IP & port filters).

It was not merely surprising behaviour, it was incorrect behaviour.  If
it was just a documentation issue, Tom would have released corrected
documentation rather than a corrected script.

--
Paul
<http://paulgear.webhop.net>
--
Did you know?  Using HTML email (or "Rich Text" email) rather than plain
text is less efficient, and makes you more vulnerable to security flaws
in your computer software.  Learn more about securing your computer at
<http://www.kb.cert.org/vuls/id/713878>.

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Paul Gear
* Paul Gear:

> The maintainer is not the problem.  Lorenzo has prepared 2.2.3-2 for
> sarge [1] and has tested the before and after situations and found that
> the bug is fixed.  The problem is no response from Martin Schulze.
>
> [1] http://idea.sec.dico.unimi.it/~lorenzo/tmp/

This information should be added to the bug report, otherwise others
might duplicate his work.

This is part of the reason why I suggested to Cc: bug reports when
interacting with the security team (if possible, that is for
post-disclousre discussion).


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Paul Gear
* Paul Gear:

> Florian Weimer wrote:
>> ...
>> It seems that shorewall generates an ACL that ACCEPTs all traffic once
>> a MAC rule matches.  Further rules are not considered.  The
>> explanations in version 2.2.3 seem to indicate that this was the
>> intended behavior, but its implications surprised upstream, and a
>> corrected version was released.
>
> That's not an accurate summary of the Shorewall team's stance.  It is a
> simple bug.  When someone uses MAC filtering in their firewall rules, it
> was always intended that a system which passed the MAC filter still be
> subject to the other rules (IP & port filters).

# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in /etc/shorewall/maclist. If
# there is a match then the source IP address is added to the 'Recent' set for
# that interface. Subsequent connection attempts from that IP address occuring
# within $MACLIST_TTL seconds will be accepted without having to scan all of
# the entries. [...]

Highly ambiguous at best. 8-(

The behavior of the MAC filter is not documented at all.

Anyway, this subthread won't lead us to a DSA.  Tomorrow, I'm going to
set up shorewall in my lab and reproduce the bug.  Hopefully that's
more productive (in some weird sense, of course).


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#318946: Info received (was Bad press again...)

Debian Bug Tracking System
In reply to this post by Florian Weimer
Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Lorenzo Martignoni <[hidden email]>

If you wish to continue to submit further information on your problem,
please send it to [hidden email], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Michael Stone-2
* Michael Stone:

> On Tue, Aug 30, 2005 at 12:17:22AM +0200, Florian Weimer wrote:
>>I think this part of the diff is pretty instructive, together with
>>upstream's explanation:
>
> Frankly, no, it's not.
>
>> if [ -n "$MACLIST_TTL" ]; then
>>    chain1=$(macrecent_target $interface)
>>    createchain $chain1 no
>>-    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j $chain1
>>-    run_iptables -A $chain1 -m recent --update                        --name $chain -j ACCEPT
>>-    run_iptables -A $chain1 -m recent --set                           --name $chain -j ACCEPT
>>+    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j RETURN
>>+    run_iptables -A $chain                                                          -j $chain1
>>+    run_iptables -A $chain  -m recent --update                        --name $chain -j RETURN
>>+    run_iptables -A $chain  -m recent --set                           --name $chain
>> fi
>
> I still have no idea what "chain1=$(macrecent_target $interface)" means.

It evaluates to the recent match chain for the particular interface.
There is one such chain for each interface on which this feature has
been enabled.

> I'm not sure why there's both an "update" and an "rcheck"--the man page
> says they're equivalent, except that update has an additional side
> effect. But if that's the case, why put the update in at all, since
> there's a return after the rcheck and you'll never get to the update.

The chains are different, $chain vs. $chain1.

> Presumably that has something to do with the mysterious chain1.  If we
> pull up the full source we find that macrecent_target
> is defined as
> macrecent_target() # $1 - interface
> {
>    [ -n "$MACLIST_TTL" ] && echo $(chain_base $1)_rec || echo RETURN
> }
> and we enter a maze of twisty functions, all alike.

It evaluates to eth0_rec in my test setup (in contrast to eth0_mac for
the chain which performs the actual MAC checks).  The relevant part of
the ACL loooks like this:

Chain eth0_in (1 references)
 pkts bytes target     prot opt in     out     source               destination        
   20  1734 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
   20  1734 eth0_mac   all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW
  985  757K net2all    all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain eth0_mac (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    4   240 eth0_rec   all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: CHECK seconds: 120 name: eth0_mac side: source
    1    60 eth0_rec   all  --  *      *       212.9.189.171        0.0.0.0/0           MAC 00:0D:60:39:11:D8
    0     0 eth0_rec   all  --  *      *       212.9.189.165        212.9.189.175      
    0     0 eth0_rec   all  --  *      *       212.9.189.160/28     255.255.255.255    
    0     0 eth0_rec   all  --  *      *       212.9.189.160/28     224.0.0.0/4        
   15  1434 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:'
   15  1434 reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain eth0_rec (5 references)
 pkts bytes target     prot opt in     out     source               destination        
    4   240 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: UPDATE name: eth0_mac side: source
    1    60 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: SET name: eth0_mac side: source


Note the ACCEPT in eth0_rec.

What further information do you need?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Paul Gear
In reply to this post by Florian Weimer
Florian Weimer wrote:
> ...
> # When a new connection arrives from a 'maclist' interface, the packet passes
> # through then list of entries for that interface in /etc/shorewall/maclist. If
> # there is a match then the source IP address is added to the 'Recent' set for
> # that interface. Subsequent connection attempts from that IP address occuring
> # within $MACLIST_TTL seconds will be accepted without having to scan all of
> # the entries. [...]
>
> Highly ambiguous at best. 8-(

It makes perfect sense to me...  All it's saying is that IP-to-MAC
mappings are cached in the 'Recent' set for each interface for
$MACLIST_TTL seconds without requiring them to be passed through the MAC
filter for every packet.

> The behavior of the MAC filter is not documented at all.

http://www.shorewall.net/MAC_Validation.html

"Not documented at all" is not a phrase i've *ever* heard used about
Shorewall.

> Anyway, this subthread won't lead us to a DSA.  Tomorrow, I'm going to
> set up shorewall in my lab and reproduce the bug.  Hopefully that's
> more productive (in some weird sense, of course).

What you do in your lab is up to you, but isn't that a bit of a waste of
time when Lorenzo has already done it?  He just told me that he sent the
results of his testing to the security team in his original request for
a DSA.

--
Paul
<http://paulgear.webhop.net>
--
Did you know?  If you receive a virus warning from a friend and not
through a virus software vendor, it's likely to be a hoax.  See
<http://gear.dyndns.org:81/features/virus_hoaxes> for more info.

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Paul Gear:

> It makes perfect sense to me...  All it's saying is that IP-to-MAC
> mappings are cached in the 'Recent' set for each interface for
> $MACLIST_TTL seconds without requiring them to be passed through the MAC
> filter for every packet.

The problem is this sentence: "Subsequent connection attempts from
that IP address occurring within $MACLIST_TTL seconds will be accepted
without having to scan all of the entries.".  What does "accepted"
mean in this context?  Accepted without further checks?

Of course, the intent was that only MAC list checks are skipped.  But
the same developer who implemented the maclist feature probably wrote
that documentation, and missed the crucial RETURN/ACCEPT distinction.

> "Not documented at all" is not a phrase i've *ever* heard used about
> Shorewall.

The syntax is documented, but not the semantics. 8-)

> What you do in your lab is up to you, but isn't that a bit of a waste of
> time when Lorenzo has already done it?

The guidelines in the Developer's Reference suggest that the
communication with the security team is not archived in the relevant
bug report, even if the bug itself is public.  So I didn't know about
his activities.

> He just told me that he sent the results of his testing to the
> security team in his original request for a DSA.

Yes, in the meantime, I've been told that, too.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12345