> > plus anyone caring to exploit a setuid root executable buffer overflow
> > flaw can send bogus signals to get the protection turned off.
>
> Wrong. Read that message with the 2nd patch once again. :)
doh, true ;)
> > i would suggest to turn executable stack off only for setuid exec()'s
>
> What about daemons? These are even more important, and, as I'm going to
> explain when posting the final patch, removed stack execution permission
> is possible to bypass in less cases when exploiting remotely than locally.
Generally i would solve these types of problems by putting an extra label
onto the executable, which says 'danger, turn stack execution off totally,
except for signal handlers'. I would >force< daemons which are not coded
properly to go down and die. [but one could define a more lax category
too, with the GFP handler solution, a matter of taste].
> So, if such an enable/disable bit is implemented (currently there're only
> lines that you could put in a program's source code for that purpose), it
> seems to be more reasonable to put it into the POSIX.6 privilege bitmask
> (BTW, is anyone still working on that stuff?), or something like that,
> instead of just using suid bit.
yeah. maybe this feature could be integrated into LinuxPrivs and resource
fork concepts.
> However, I don't think this is really required, since with the GPF handler
> everything seems to run just fine, and the stack is non-executable where
> possible.
yep but if we want to see this as a regular kernel feature (and i'd like
to ;), we've got to prevent processes taking one more fault per lifetime.
[say LinuxThreads would suffer, amongst other applications]
it's a cool patch, but this extra fault thing is IMHO a rough edge ;) [the
extra GFP branch does not seem to be a problem, as it's not common code]
This is the Linux kernel and we are counting cycles big time ;)
-- mingo