Re: secure computing for 2.6.7

[Andrea Arcangeli]

Hi Andi,

On Mon, Aug 02, 2004 at 02:05:20AM +0200, Andi Kleen wrote:
> I don't think a sequence number is a good idea. Consider a
> vendor/third party kernel fixing a security bug, but mainline hasn't
> taken the patch yet for some reason.

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

> The vendor kernel could not safely increase this number, because it 
> could conflict with some other security bug fixed in mainline at the 
> same time. 

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.

> A safe solution would be a file in /proc that lists CAN idenitifiers of
> fixed bugs or similar, but that may be quite some overhead to maintain
> and parse.

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/