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.
>
> 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.
>
> 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?
>
> 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
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
