>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