[OpenAFS] When to publish security advisories?

Stephan Wiesand stephan.wiesand@desy.de
Fri, 15 Apr 2011 20:18:59 +0200


Hi Simon,

On Apr 15, 2011, at 19:53 , Simon Wilkinson wrote:

> 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.
>=20
> 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.

the problem is that "DOS only" problems tend to become "privilege =
escalation" ones once a smart attacker looks at them. And often in ways =
the developers/maintainers don't expect.

> My proposal, going forwards, is to not produce security advisories or =
releases for these local denial of service attacks.

Whenever you're completely confident that there's no way to exploit the =
bug for privilege escalation, that's fine.

> 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.
>=20
> 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?

I have applied, as well as backported, them to packages I've supported a =
few times in the past. Yes, they are useful.

> 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?
>=20
> I'd welcome feedback about both of these.

It really depends on what you call a "normal stable release". In =
particular, 1.4.8 was not a stable release IMO. Subsequent releases =
weren't either, at least up to 1.4.11. And 1.4.12 and 1.4.14 are still =
broken for one of our most important use cases - 1.4.7 handled it well.

So, frankly, the collected security fixes against 1.4.7 would be =
extremely useful. We'd probably start running this "super stable point =
release" tomorrow on >1000 systems if it were available.

Hope this helps,
	Stephan