Re: executable stacks, a few suggetions
Tue, 15 Apr 97 00:57:07 +1100

>> 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