[lkml]   [1997]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectexecutable stacks, a few suggetions

    On Mon, 14 Apr 1997, David S. Miller wrote:

    > When you say "those executing code on the stack will have stack
    > execution permission automatically enabled" you do realize that any
    > program which has a signal delivered to it will "execute code on the
    > stack" via the kernel itself? Since just about every program I know
    > of which is of any utility takes a signal now and then during normal
    > operation, doesn't this turn off your protection in enough cases to
    > make it of little use?

    plus anyone caring to exploit a setuid root executable buffer overflow
    flaw can send bogus signals to get the protection turned off.

    ok, this one can be circumvented by ignoring >all< signals. Thus the point
    is the following: if this patch is used, AND the executable disables
    signals, then buffer overflows are less dangerous. [maybe the point is
    that most setuid root executables ignore signals already?]

    but then >every< executable takes one more fault (which turns executable
    stacks on), which isnt too cool performancewise.

    i would suggest to turn executable stack off only for setuid exec()'s
    only. Maybe this latter one is the coolest? exec()-ing takes sooo much
    time anyways, these few instructions are lost in the noise [and they are
    only needed for those few setuid programs]. (and admittedly, buffer
    overflows are a major pain, and i would love seeing them reduced)

    for setuid root processes i would even install a bit more code, just to
    make them more secure: after a signal handler returns, i would turn off
    execution bits again. Maybe there are a few more cases where execution
    bits can be turned off again. >maybe<. The major idea is to check for
    setuid executables at exec() time [we have that branch already].

    -- mingo

     \ /
      Last update: 2005-03-22 13:39    [W:0.019 / U:10.604 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site