Messages in this thread | | | Date | Mon, 14 Apr 1997 13:59:08 +0200 (MET DST) | From | Ingo Molnar <> | Subject | executable 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
| |