Messages in this thread | | | Date | Fri, 7 Aug 1998 23:50:47 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: Stack Smashing and no-exec |
| |
On Fri, 7 Aug 1998, Pete Harlan wrote:
> Trever writes: > > keep the system safe. Root is supreme, root is the OS in many ways. If > > root takes the system down, heck, that is roots fault. So the mentality > > that the OS should protect root from himself (note generic him, none of > > So we shouldn't segfault root-owned processes that write outside their > memory either. That should cut down on sig11's when compiling the > kernel now that you mention it.
No no no. Of course you *try* to catch the problems, you just don't *guarantee* that they will all be caught. You also don't tie the system in knots trying to protect it in every conceivable way. It is all a matter of priorities. When it comes to fixing situations where non-root userspace code can break the kernel, your only real option is to fix the kernel because that is never supposed to be possible under any circumstances.
But if you are running code as root in userspace, you have another option. You can fix the offending userspace code. And this option *works* - the security hole will be fixed. And it *is* a bug in the userspace code, and bugs should be fixed once spotted. You can also fix the kernel, of course, but then you get into the issue of priorities. At some point the cost of rejiggering the kernel becomes prohibitive.
At some point, you have to admit that suid root code is in effect part of the OS, at least as far as priviledge is concerned. Given that, it doesn't make sense to tie the OS in knots trying to protect it from itself. If I am writing a device driver module that tries to dereference a null pointer, I will get an oops and the kernel will probably be able to continue functioning. But it also might not - the driver might have changed some part of the kernel to use the module, and when the kernel tries to use the dead module it will cause more oopsen and eventually a lockup.
The point is that, while the kernel made a good-faith effort to catch errors in my driver, it did not try to *ensure* that this was always possible. The bottom line is that there is no acceptable substitute for my driver working correctly. I consider suid root userspace code to be no different. Such code has responsibilities that come along with its privileges, and one of those responsibilities is to shoulder some of the burden of ensuring system stability.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |