lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:2.877 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site