Re: Stack Smashing and no-exec

Jon M. Taylor (taylorj@ecs.csus.edu)
Fri, 7 Aug 1998 23:50:47 -0700 (PDT)


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