[lkml]   [1997]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: executable stacks, a few suggetions
    >> 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

    I've sent a private Email to David suggesting that this feature could be enabled only when running with root privs (making it SUID/SGID only is not enough as a SUID program could run dozens of other programs which may be buggy). Then even if the feature was totally incompatible with Objective C (not that it is) this wouldn't be a problem as AFAIK no-one uses O-C to write system programs or other programs which need to run as root.
    It has also just occurred to me that we could have a tunable under /proc to specify the highest UID that is used for such checking. I have web servers and other servers running with UIDs < 100 so I'd set it to 100. Then my web server would be more secure and users could run what they want.

    As for signals I thought the idea was to enable stack-execution for the duration of the signal and then turn it off again after signal processing had ended. There is the problem of programs which use setjmp()/longjmp() in signal handlers, but we can't plug all security holes...

    Also this could be a compile option, maybe for servers only. I have been reading about so many people having problems with things like >48 serial ports etc that I think there should be a compile option for COMPILE_AS_SERVER to give much larger resource allocations and to enable features such as this which aren't of much use to the home-user.

    Russell Coker

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