Messages in this thread | | | From | David Mosberger <> | Date | Tue, 23 Mar 2004 23:45:09 -0800 | Subject | Re: Non-Exec stack patches |
| |
>>>>> On Wed, 24 Mar 2004 02:28:40 -0500, Jakub Jelinek <jakub@redhat.com> said:
Jakub> On Tue, Mar 23, 2004 at 11:16:36PM -0800, David Mosberger Jakub> wrote:
>> 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 Jakub> constructors).
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().
--david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |