Messages in this thread | | | Date | Mon, 2 Aug 2004 18:31:13 +0200 | From | Andrea Arcangeli <> | Subject | Re: secure computing for 2.6.7 |
| |
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |