Re: Non-Exec stack patches
From: David Mosberger
Date: Wed Mar 24 2004 - 02:47:46 EST
>>>>> On Wed, 24 Mar 2004 02:28:40 -0500, Jakub Jelinek <jakub@xxxxxxxxxx> said:
Jakub> On Tue, Mar 23, 2004 at 11:16:36PM -0800, David Mosberger
>> I'm not following you on the "get ld.so handling free" part. How
>> is that handling free?
Jakub> What I meant is that it is already written and tested.
OK. The ELF flags bit is even more free, then... ;-)
>> Actually, that's something that worries me. Somebody just needs
>> to succeed in loading any shared object with the right
>> PT_GNU_STACK header and then the entire program will be exposed
>> to the risk of a writable stack. On ia64, I just don't see any
>> need to ever implicitly turn on execute-permission on the stack,
>> so why allow this extra backdoor?
Jakub> What kind of backdoor is it? If you dlopen untrusted shared
Jakub> libraries into your program you have far bigger problem than
Jakub> executable stack (you can execute any code it wants in its
Sure. Theoretically, none of this matters at all (thanks to
mprotect()), so we're justs talking about raising the barrier. With
PT_GNU_STACK, it's sufficient to tweak one bit in any dependent
library, whereas with the ELF flag bit, you need to tweak one bit in
the main executable. Not a huge difference, I'll submit, but from an
admin perspective, I find it a lot easier to check the main program to
see if it has the "executable stack/data" bit set rather than all
dependent libraries. Additionally, we could easily choose to drop
support for the ELF flag bit altogether. The only program that I know
of that ever needed executable data was XFree86 and that was only due
to an oversight---and that has long been fixed.
Jakub> If there is a shared library which needs executable stack for
Jakub> its use (on !IA64 !PPC64 this is e.g. any library which takes
Jakub> address of a nested function and passes it to some other
Jakub> function and/or stores it into some variable which cannot be
Jakub> optimized out, on IA64 or PPC64 this is of course much rarer,
For sufficiently small values of "much rarer", I agree. ;-)
Jakub> but it is still possible some language interpreter or
Jakub> something builds code on the fly on the stack).
That's why there is mprotect().
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/