Re: Bad press again...
* 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.
Reply to: