Messages in this thread | | | Date | Mon, 2 Aug 2004 23:35:22 +0200 | From | Andrea Arcangeli <> | Subject | Re: secure computing for 2.6.7 |
| |
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). - 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/
| |