* 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
