[OpenAFS] When to publish security advisories?

Simon Wilkinson sxw@inf.ed.ac.uk
Fri, 15 Apr 2011 18:53:08 +0100


Hi,

One of the issues that comes up from time to time is what actually =
constitutes a bug worthy of a security advisory. Sometimes this is =
really clear cut, but in other areas, in particular in relation to our =
Unix kernel modules, the dividing line is significantly less clear. =
Getting this right is important. On one hand, we have an obligation to =
make people aware quickly when there is an issue that affects the =
security of their systems. On the other hand, when a change addresses a =
security issue we have historically made a release containing just that =
change. Making security releases is expensive and time consuming - it =
removes developer effort from all of the other things that we want to =
get done, and delays the arrival of releases that actually contain new =
code.

The problem is that any programming mistake in our kernel module will =
generally result either in the machine locking up, or in the AFS =
filesystem becoming unusable. We generally find out about these mistakes =
because a local user triggers them, so from a security point of view, =
virtually all of them are a local denial of service attack.

My proposal, going forwards, is to not produce security advisories or =
releases for these local denial of service attacks. Local issues that =
can result in privilege escalation, or denial of service attacks that =
can be performed by those outside a sites infrastructure would still =
result in advisories.

My supplemental question, is just how much use the "security releases" =
actually are. Most of our packagers ignore them, in favour of pulling =
the patches that we release with the advisory into their packaging. Is =
just providing these patches sufficient? Is there actually a demand for =
a "super-stable" point update that just contains the security code, or =
is it acceptable to provide the security fix as part of a normal stable =
release?

I'd welcome feedback about both of these.

Cheers,

Simon.
(with his OpenAFS Security hat on)=