Re: secure computing for 2.6.7

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Aug 01, 2004 at 11:17:19PM -0400, Horst von Brand wrote:
> Andrea Arcangeli <andrea@suse.de> said:
> 
> [...]
> 
> > note this isn't a build number (the features in 2.6.10 don't matter at
> > all, the only thing it matters is that all security bugs up to 3503 are
> > included).
> 
> Pray tell, how do you know if a random "compiler warning fix" isn't a plug
> for an exploitable hole, and if a "security fix" really does fix a real
> security problem that can be abused?
> 
> Truth is, you can never know. So, this degenerates into sequential patch
> numbering, which is completely hopeless.

nothing is perfect. keeping track of a few sporadic kernel builds with
unsafe compiler with `uname -r` is quite easy compared to keeping track
of every security `uname -r` out there. It's about the common case
working well (common case is like fnclex), corner cases will have to be
handled with a db anyways, but it'll be much simpler to single out a few
spoardic `uname -r` than to keep track of everything in the common cases
too.

For example if a new bug triggers only on a certain buggy future cpu, I
don't want to shutdown the whole thing but I'll have a db that will
single out only such specific cpu if the security_sequence is lower than
N.

But anyways I start to think I should probably rename it to
seccomp_security_sequence, so that it's not going to degenerate in the
sequential patch numbering and it'll really work well for the common
case since there's a seccomp relevant bug less than once every 2 years
or less (and half the time they're hardware related and not a software
issues).