On Tue, 12 Apr 2005 12:06:59 +0545, Bipin Gautam said: > every to verify its types) On the other hand we have had products like > stack guard, lib safe, grsecurity.net, se-linux
> BUT i was woundering, to what extent adding these extra security > measures are effective against the real attacks & bugs discovered in > the kernel. They do almost nothing to guard against bugs discovered *in the kernel*, because all of them are addressing *userspace* bugs. There's pretty much *zero* you can do to protect against kernel bugs, other than audit the code and get rid of the bugs. Remember it's basically a monolithic kernel - that means that if a bug lets somebody get control of the kernel, it's Game Over. There's a reason why binary kernel modules are frowned upon - and it's precisely that. As far as the kernel is concerned, a security bug and a buggy binary module are the same thing - both can go scribbling on whatever kernel data structures it wants to, and there's no real way to stop it. If anybody wants a good kernel-auditing project, just start going through the 2.6.12-rc2 tree and look at uses of copy_from_user(), and make sure that each use of that function then proceeds to *validate* the data (especially in the various driver's .ioctl methods - historically a place for issues). At least the tree seems to be a lot better with not ignoring the return value of copy_from_user() ;)
pgpxBy9hoZqMd.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
