Re: secure computing for 2.6.7

[Andrea Arcangeli <andrea@cpushare.com>]

On Mon, Aug 02, 2004 at 03:06:48PM -0400, Rik van Riel wrote:
> Think EVMS in a certain SuSE kernel.  Hard to imagine
> no security bugs got fixed in that code ;)

we make sure they're obviously safe in security terms before applying so
that was really a bad example.

But let's assume there's a real seccomp relevant bug in a RH kernel,
it's still zerocost to bump the security sequence all over the place (in
SUSE and mainline too), just like 2.4 would need to bump the sequence
number too if we find a 2.6-only bug. So there's absolutely no problem
at all even in such a case.

The only issue I can see after the complains I heard so far, is that
it could be too complicated for the community to synchronize and agree
on the ID for every security related patch (rejects pain or inefficient
communication could make it not feasible).

But seccomp bugs are so rare and so extremely severe for the whole
userbase (not only for people using seccomp mode, think f00f or fnclex
or mmx sniffing) that this will actually work fine, just like I hope we
can successfuly agree and synchronize on the syscall numbers that also
are added rarely.

What I mean is that the seccomp_security_sequence is going to work fine
as far as the syscalls works fine, and that's the only thing I need as
far as cpushare is concerned.

But I certainly agree with Andi that we might prefer to take the CAN
way, that way it won't help only seccomp userbase, and it'll be possibly
easier to maintain since we don't need to synchronize ourself, but we'll
relay on somebody else to issue unique ID for us which makes the ID
selection a no brainer. plus it provides a bit more of information just
in case somebody forgot to fix a security bug. Though I'd expect heavy
rejects on that file if you forget to apply a security fix (which to me
was a feature but apparently somebody thinks is just lower flexibility
to get rejects if your kernel is going to be insecure).