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