As far as I understand it, from the perspective of the security team,
it is not clear if the upstream change breaks existing user
configurations. Users might rely on the current behavior and use it
to deliberately weaken the filter policy. This is a reasonable
question because the existing documentation is quite unclear about
what MAC filters actually do.
There are actually two behavioral changes we are talking about.
The MACLIST_DISPOSITION=ACCEPT case is the easy one. If the user has
activated this option, all hosts listed in the "maclist" configuration
file are still filtered as desired. However, packets from any host
whose MAC address is NOT listed there are accepted (and forwarded) by
the firewall. (As far as I can see, this is not what has been
described before, but I've checked that this is really the case.)
This means that this behavior is virtually useless, and it is
extremely unlikely that anyone uses it deliberately.
The other case is MACLIST_TTL=nnn. This is a bit more complicated
because the effect is restricted to hosts listet in "maclist" only.
These hosts can bypass the remaining filter rules, so this might
actually be useful in some scenarios, although it completely bypasses
shorewall's zone concept. However, the MACLIST_TTL=nnn setting is
documented as a performance optimization only ("The performance of
configurations with a large numbers of entries in
/etc/shorewall/maclist can be improved by setting the MACLIST_TTL
variable."). Despite the ambiguity of the documentation, this makes
it rather unlikely that users have discovered this behavior and use it
deliberately to implement their filtering policy.
I've also skimmed the shorewall-users mailing list, but couldn't find
a complaint that the firewall behavior changed in an unanticipated way
after the security upgrade.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
