secure computing for 2.6.7

Hi Andi,

does this really happen? The thing I'm thinking about here is the fnclex and f00f kind of bugs. Or even worse ones. Those bugs area _always_ fixed in mainline too. Maybe I should simply rename it to seccomp_security_sequence instead so nobody has to touch it for years (ideally forever ;).

Also note, not increasing the sequence number isn't fatal, false positives are fine, what I cannot accept are false negatives. So if mainline didn't issue the new number yet, nobody would be forced to increase that number. As far as I'm concerned (for my usage) I would take care of pushing the fix into mainline myself, so I'm not worried about mainline not including the security fixes.

This is all about disaster recovery, it doesn't necessairly need to be efficient if the thing is difficult to fix (like workarounding future nasty hardware bugs, which may take time), it only must be safe. Even if mainline increases the number after months I don't mind as far as no false negatives are generated.

For relatively easy things like fnclex that didn't clear the exceptions, vendor-sec would be the place assigned to increase the numbers so that new kernels would be synchronized and released with a new number all at the same time (including mainline).

Yep. But the vendor kernel isn't forced to increase it, as far as it doesn't create false negatives that's fine, it's not that urgent to increase it.

this would be perfectly fine too, the only bad thing is the wasting of kernel memory for that. 1 byte of securty_sequence was a minor issue. If we go this way, then we should be build knowledge into the boot process so that this information is dumped into /var/log/kernel_security as world readable during boot time, and then released from the kernel (this shouldn't be too difficult to implement).

building the uname -r universal vendor database for every possible distro version is doable too, I don't strictly need to add this security_sequence (or even better a CAN list to dump in a kernel_security directory), but I feel much safer (and I'd be a lot simpler) in having a vendor neutral standard way to check if the kernel is secure enough to run stuff in seccomp mode than to relay on uname -r checks.

Think EVMS in a certain SuSE kernel. Hard to imagine no security bugs got fixed in that code ;)

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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).

What about using the kernel version (instead of a seq #) plus a /proc file which lists the fixed CAN ids? This way a patch to a kernel will add an entry to /proc/koko and the program whould check the kernel version. If the kernel version is less or equal to X then it will read the /proc/koko for applied patches.

When a new version of the kernel is released then the /proc/koko file will be cleared a bit since version X.Y.Z means that the patches were added.

This leads to a hole between releasing a new version of the program and releasing a new kernel version, since the author will not be able to know if the next version of the kernel will have this bug fixed or not, so he cannot safely check the kernel version for a >X.Y.Z.

This can be solved in combination with a user space library that maintains a list of known kernel fixes and an API like: int can_is_fixed(...); which will combine the /proc information with the kernel version. The library (i.e an /etc file) will maintain a list of known fixes and the kernel version it was applied and will read the /proc/koko file for extra information. This may lead to false positives in case the library is an older version and the kernel is upgraded (since the lib will not know about the applied patch) but:

a) This is acceptable by the conditions you've set
b) Can be partialy solved by keeping CAN ids in /proc/koko for N versions of kernel (or for N months)

<<V13>>