lkml.org 
[lkml]   [2004]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.082 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site