lkml.org 
[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds
    Date
    To not produce a number of replies that deal with the same issue, I decided to
    comment on a couple of mails in one reply. I appologize if this causes any
    inconvenience.

    [1]On Tue, 04 Aug 1998, Linus Torvalds wrote:
    >I chose libc mainly because it's the obvious choice, but your example
    >makes it just all the more clear that the whole approach of the patch is
    >not to fix real problems, but to fix specific attacks that really should
    >have been fixed in the binary.

    Can you please define 'real problem'?

    [2]On Wed, 05 Aug 1998, Linus Torvalds wrote:
    >In short, my argument is not that the kernel should not try to make things
    >secure for you. My argument is that no-stack-exec adds nada, zero, zilch,
    >nothing in the form or real security.

    I agree with you completely that the no-stack-exec patch provides a marginal
    security of exactly zero. However, UNIX is broken with respect to security _by
    design_, and _already is_ full of various ad hoc solutions that try to solve
    individual security related problems.

    The particular problem of stack smashing is an example of a security related
    problem that, in the existing paradigm, _cannot_ be fully and cleanly solved.
    The right solution for this particular problem is to enable building of objects
    that support the principle of least authority - when an object only contains the
    authority to manipulate a string in a page of memory (but not also the authority
    to spawn a root shell), the stack smashing problem is no more. So, the solution
    is easy: build the system from small, highly specialized objects that each
    contains an insignificant amount of authority, such that in case of a buggy
    object the attacker can't get sufficient power to do anything really bad, thus
    limiting the damage that can be done by exploiting such a buggy object.

    Unfortunatelly, UNIX systems, including Linux, are _by design_ (and by choice
    since we prefer to keep the system fast (but insecure) on a crappy architecture
    like x86, where (among numerous other deficiencies) border passing is slow,
    instead of making it a bit slower (but at least secure) on crap but fast (and
    also secure) on better architectures - this is not Windoze, we can actually
    CHOOSE what we want to run our applications on, can we?) made of _large_
    objects that, by definition, _cannot_ support the forementioned principle. So
    the only solution that can at all exist in such an environment is an ad hoc one
    that will only partially solve the problem.

    The no-stack-exec patch is such a solution. And it does try to solve a _real
    problem_. It's not a complete one, but it's the best one there is at the moment
    and probably the best one there ever will be for this particular problem in
    this particular type of environment.

    [3]On Wed, 05 Aug 1998, Linus Torvalds wrote:
    >Or sombody had better tell me why they shouldn't fix their broken
    >applications.

    You can run away from the problem by telling other people that they should fix
    it for you by fixing their applications. You can't hide from it though, since
    it's the _kernel's_ job to protect the system in the first place, and this
    being the case, the solution (whatever it may be) _belongs_ into the kernel. If
    you want a secure system, you can't let a broken application compromise it. You
    know that, because that's one (of many) of the reasons why we use protected
    memory.

    [2 cont.]
    >No, you may not be open to old exploits if you have the no-stack-exec
    >patch. But old and known stack exploits aren't the issue:

    Basically, there are three options available: to ignore the problem and hope
    that it will go away (which it won't); to implement an ad hoc solution, such as
    the no-stack-exec patch, that at least partially solves it; or to change the
    paradigm upon which Linux is built, thus making the stack smashing problem go
    away forever.

    Since future and unknown stack exploits are the issue, what solution do you
    suggest we implement?

    In the short run, I would (if I may) recommend a config option for the
    no-stack-exec patch. For a few simple reasons: it's has been and _is_ being
    used by people who consider stack smashing to be a _real problem_, it is known
    what problems it cures, what problems it doesn't and what problems it creates,
    so people can work on them, and it's the best solution for the problem that is
    available _now_.

    But in the long run... Well, I guess that in the long run, the choice is still
    yours.

    Andrej

    --
    Andrej Presern, andrejp@luz.fe.uni-lj.si

    -
    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.567 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site