Recently there has been a fair ammount of bugs showing up in our bugzilla system where users are reporting problems like "cannot enable executable stack as shared object requires: Permission denied" I had thought till this morning this was limited to gcc-3.3.x only but the first bug showed up where a user reported this happening with gcc-3.2.3. Anyway do to the sheer number of these bugs showing up and all being reported as something diffrent I'd like to suggest that a unifined bug be used for tracking reasons.
Created attachment 20404 [details, diff] glibc-2.3.2-dl_execstack-PAX-support.patch After talking with pappy and pipacs, it seems like this is due to PaX 'write-protecting' the stack, and ld.so then trying to make the stack executable due to some libraries not containing the PT_GNU_STACK section. Here is an temporary patch to glibc-2.3.2-r8 that *should* fix this for the moment.
Log of pipacs (author of PaX) explaining the issue: -- [01:50] <pipacs> so what's the topic exactly? [01:51] <pappy-> okay, we are talking about the http://dev.gentoo.org/~pappy/pax/PT_GNU_STACK.txt problem [01:51] <pappy-> and what happens to the PaX MPROTECT feature making the stack nonexecutable by default [01:51] <Azarah> wondering how difficult it will be to get it to work with PT_GNU_STACK (if ever) [01:51] <pipacs> it's not only by default, you cannot change it later either, that's what breaks ld.so [01:51] <pappy-> pipacs: which is a security feature rather than a bug [01:52] <pipacs> Azarah, the problem is that the whole concept of PT_GNU_STACK is wrong from my point of view [01:52] <pappy-> what Redhat is trying to achieve is some kind of more general OpenBSD W^X oriented approach with the PT_GNU_STACK behaviour per binary [01:52] <pipacs> so if i were you, i'd ditch all of that code at once [01:52] <Azarah> pipacs: isnt the whole point of a stack protection scheme not to have stack executable ? [01:52] <pipacs> Azarah, bingo ;) [01:52] <Azarah> pipacs: i have not read up on rh's stuff [01:52] <pappy-> Azarah: this is true, yes. [01:53] <Azarah> pipacs: so not sure why they need it executable .. ? [01:53] <pipacs> but the problem is, some apps (for one reason or another, mosly for wrong reasons) wnat an executable stack [01:53] <pappy-> what Redhat is trying to achieve is some kind of compatibility features of binaries. [01:53] <pipacs> that's ok, you can use chpax for now to allow it [01:53] <pipacs> what redhat did is to automate what the manual use of chpax does [01:53] <Azarah> ok [01:53] <pipacs> their automation is code that ended up in all the toolchain [01:54] <Azarah> reason why chpax do not work for guys who's systems are breaking ? [01:54] <pipacs> it starts w/ gcc taht detects code sequences in source code that *may* suggest the need for an executable stack [01:54] <pappy-> pipacs: they automated it the inversive way: they enabled executable stack for every binary that is not consisting hundred percent of PT_GNU_STACK [01:54] <Azarah> pipacs: well, rh is the toolchain these days :/ [01:54] <pipacs> Azarah, sure, i'll talk about that too [01:54] <pipacs> let me just finish what redhat did, unless you already know the story [01:54] <pappy-> pipacs: go ahead :-) [01:54] <Azarah> sorry =) [01:55] <pipacs> so, gcc has some heuristics to detect the need for an executable stack [01:55] <pipacs> like whenever a nested function or inline assembly construct is used [01:55] <pipacs> every .o file emitted by gcc will have a special section that describes what stack the given .o wants [01:55] <pipacs> then at link time ld will collect that info and produce a PT_GNU_STACK segment [01:56] <pipacs> the access rights on that segment will determine for the entire module (ET_EXEC or ET_DYN file) what stack it wants [01:56] <pipacs> next comes the kernel and ld.so [01:57] <pipacs> their kernel (w/ exec-shield) in it will parse/detect PT_GNU_STACK in the main executable (and maybe ld.so too, i forget) [01:57] <pipacs> and automatically make the stack executable [01:57] <pipacs> if neither of them wants an executable stack, then the process will start its userland life w/ a non-exec stack [01:57] <pipacs> next comes ld.so however which can still override it and try to make the stack executable [01:57] <pipacs> it can do it for two reasons [01:58] <pipacs> 1. if any of the libraries mapped into the process wants an executable stack, ld.so will ask for it from the kernel [01:59] <pipacs> 2. if there's an ELF file mapped into the process that has a PT_GNU_STACK segment, and at least one which is not marked at all (e.g. it was compiled w/ gcc 3.2.x) then for safety ld.so will still request an executable stack [01:59] <pipacs> i think what bit most people in gentoo is the second case [01:59] <pipacs> now at least this is the story i recovered so far [01:59] <pappy-> dont forget the libraries mapped in [01:59] <pipacs> what i don't know for now is how people running w/ gcc 3.2.x alone could experience this [02:00] <pipacs> that's a mystery to me, i already asked solar for strace outputs, im still waiting to get them [02:00] <pappy-> pipacs: binutils patch [02:00] <pappy-> pipacs: then new glibc is having dl_foo and their binutils happily setting up the segment [02:00] <pipacs> that other thing i don't understand is why chpax didn't help, if you disable non-exec pages altogether then the given app should work again [02:00] <pappy-> pipacs: without the spoken gcc hints [02:00] <pipacs> pappy, no kidding? [02:00] <pipacs> that can't be true [02:01] <pipacs> if it is, someone at redhat must be kicked in the butt ;P [02:01] <pappy-> pipacs: calm down [02:01] <pappy-> pipacs: we will smoke the peace pipe and make it all good [02:01] <Azarah> pappy-: what ever to binutils is then already in the tree [02:01] <pipacs> so there are some questions to answer first [02:02] <Azarah> pappy-: i have checked it earlier, but at least between .6 and .7 there is nothing related to PT_GNU_STACK [02:02] <pappy-> Azarah: they use gcc, glibc and binutils hookups to establish these features [02:02] <pipacs> 1. i need strace output from systems that claim to never have run code from gcc 3.3 and still suffering from the ld.so error message [02:02] <pappy-> Azarah: grep -ri pt_gnu_stack in your cvs and distfiles trees [02:02] <pappy-> Azarah: the unpacked binutils source [02:02] <Aether> tberman, i fixed the big bugs in java-config homie [02:02] <Azarah> pappy-: i said between .6 and .7 =) [02:02] <pipacs> 2. i need to know how to reproduce the problem w/ chpax/pax not doing its job [02:02] <Aether> tberman, I think [02:03] <pappy-> Azarah: what do you think about this issue? [02:03] <pappy-> Azarah: i would like to know what impression you have got so far. [02:04] <pappy-> Azarah: all i am thinking about is what and how we can trigger to separate the PaX behaviour from the future execshield support in the toolchain. [02:04] <Azarah> ok, was the 6th month that it was added, nothing later [02:05] <Azarah> question - how do exec-shield do protection with an executable stack ? [02:05] <pipacs> Azarah, it does not have any non-exec pages then, only randomization [02:05] <Azarah> pipacs: ah, ok [02:06] <Azarah> pappy-: i guess the question first to be answered, is what exactly hinders execution ? [02:06] <Azarah> pappy-: the stack being set exec, and pax not handling it ? [02:06] <pappy-> In my opinion, this is now decision day to estimate the work it needs to get Gentoo into further supporting PaX kernels with a splitbrained toolchain, which is what i am very sorry about. [02:07] <Azarah> pappy-: and then as pipacs already noted - why chpax do not work [02:07] <pipacs> Azarah, what exactly hinders execution - of what? [02:08] <pappy-> pipacs: can you look for dl_test_stack or test_stack in the patch [02:08] <pappy-> pipacs: i am afraid i saw something like test somewhere where the stack is acutally tested for executioness [02:08] <pipacs> pappy, i dont see that code in glibc here [02:08] <Azarah> pipacs: or rather this then: cannot enable executable stack as shared object requires [02:09] <pappy-> pipacs: in binutils maybe? [02:09] <pipacs> Azarah, ok that error comes from ld.so [02:09] <Azarah> is it ld that tries to .. [02:09] <pipacs> Azarah, it occurse because it tries to call mprotect() on the stack [02:09] <pipacs> and under pax it can't make it executable [02:09] <pipacs> now chpax -sp should fix it [02:09] <Azarah> and by this time pax already kicked in [02:09] <pappy-> pipacs: when the ld.so is chpaxed to disable mprotect, this could work then? [02:09] <pipacs> i don't know what people tried when they said it didn't work [02:10] <pipacs> Azarah, correct, pax activates the page protetions right on execve(), before anything executes in userland [02:10] <pipacs> pappy-, you don't chpax ld.so, you chpax the main application [02:10] <Azarah> pipacs: any chance to get pax to kick in a bit later ? [02:10] <Azarah> pipacs: or will the security issue be then too big [02:10] <Azarah> or risk rather [02:10] <pipacs> Azarah, no, it's not possible to do it later [02:11] <pipacs> at least not on i386/segmexec [02:11] <pipacs> Azarah and of course doing it any later is bad for security. [02:11] <Azarah> pipacs: ok, what about hooking the call ld.so makes to mprotect() ? [02:12] <pipacs> Azarah, why not simply make _dl_make_stack_executable() return 0 without doing anything? [02:13] <pappy-> pipacs: what mechanism in gentoo should trigger the applying of this pax-friendly patch? [02:13] <Azarah> pipacs: guess it will have the same effect as without the whole PT_GNU_STACK issue and something trying to use exec stack [02:13] <pappy-> pipacs: we cannot do that when the user will never use PaX or even worse, will use execshield in the future... [02:13] <pipacs> this would be a short-term solution until we can consider carefully how PT_GNU_STACK should be treated [02:13] <Azarah> pipacs: ok, how about making _dl_make_stack_executable() return 0 by default only if pax is enabled - is it possible to detect runtime ? [02:13] <pappy-> Azarah: this is a good point [02:14] <pappy-> pipacs: why not modify it a bit... [02:14] <pappy-> pipacs: i like the idea of Azarah [02:14] <pipacs> Azarah, uhm, not really, the only way to detect pax is to get killed, so that's not good ;) [02:14] <pappy-> pipacs: you could find a way for ld.so not get killed when probing [02:14] <karltk> Azarah: yeah. it's fun for now, so I keep it up. [02:14] <karltk> robbat2: most, I guess:) [02:14] <Azarah> pipacs: ok, so in what cases will _dl_make_stack_executable() fail, exept for runing under pax ? [02:15] <pipacs> Azarah, it should not ever fail then [02:15] <pipacs> but i heard reports that people running w/o pax had that message as well [02:15] <pipacs> is that true? [02:15] <Azarah> pipacs: could be then the detect() you are looking for ? [02:15] <Azarah> pipacs: i guess unless the kernel do not support it, [02:15] <Azarah> pipacs: but that is detectable ? [02:16] <pipacs> Azarah, uhm, what is detectable? [02:16] <Azarah> pipacs: if the kernel have the needed support enabled for exec-shield ... [02:17] <Azarah> bleh, let me just go and look at that [02:17] <pipacs> Azarah, well, exec-shield creates a /proc entry and you can check for its existence (plus even control it) [02:17] <pipacs> but that assumes /proc is in the kernel [02:18] <pappy-> why dont we do it the other way around [02:18] <pappy-> PaX is the older solution [02:18] <pappy-> we ensure that either PaX or without PaX the dl_make_stack_whatever is returning 0 [02:19] <pappy-> and only if the execshield stuff is found via sysctl() or kernel or whatever, the normal behaviour is restored [02:19] <pappy-> this costs you some minor kernel patching voodoo [02:19] <pappy-> and editing some functions in the glibc [02:19] <Azarah> pappy-: ill mail you the proper patch, i missed an revision [02:19] <pappy-> while ensuring that PaX will not get in trouble if the user decides to not use pax, to use pax now, to use pax later or to remove pax after using it [02:19] <pappy-> Azarah: *hehe* [02:20] <pipacs> imho, this whole binary marking approach should be rethought [02:20] <pappy-> pipacs: yes, but if redhat is getting serious with it, we have to support it in the long run [02:20] <pipacs> chpax functionality could be implemented this was as well for example [02:20] <pappy-> pipacs: and i am sure we can go this way [02:20] <pipacs> so in the future we could PT_PAX_* stuff [02:20] <pappy-> pipacs: top down, from the hardcore solution like pax, to the more mainstream solution like execshield but then activated by the trigger [02:21] <pappy-> pipacs: i personally dont want to see binaries switching MPROTECT on and off automatically via toolchain [02:21] <pipacs> pappy, my problem w/ supporting PT_GNU_STACK in pax is that it will create a less secure system than without it [02:21] <pappy-> pipacs: i am not talking about you supporting it [02:21] <pipacs> because the heuristics gcc uses produces false positives [02:21] <pappy-> pipacs: i am talking about marking the patches now depending on a future execshield hotbutton [02:22] <pipacs> and unnecessarily marks DSOs w/ an executable stack PT_GNU_STACK [02:22] <pappy-> pipacs: and setting it all up for PaX to continue working as usual [02:22] <pappy-> pipacs: so that when execshield enters gentoo for whatever reason, we can modify the patch and set it up accordingly [02:22] <pappy-> i want it the other way around as it is implemented now [02:22] <pipacs> well, if you can separate out the PT_GNU_STACK part of glibc/etc and activate it only on user defined conditions, all the better for me [02:22] <pappy-> we need to disable it and only enable this execshield PT_GNU_STACK behaviour when only a execshield kernel is found [02:22] <pipacs> but that's some work for you then [02:23] <pappy-> pipacs: not on user defined conditions but on conditions of the running kernel [02:23] <Azarah> pipacs: the only error ENOMEM Not enough space [02:23] <Azarah> arg [02:23] <pipacs> Azarah, where did you get that from? [02:23] <pappy-> we can enter a sysctl(REDHAT_EXECSHIELD) into the kernel to enable it explicityl [02:23] <Azarah> pipacs: the only error _dl_make_stack_executable handles is ENOMEM [02:24] <pipacs> Azarah, ah that, yes i noticed it too [02:24] <Azarah> pipacs: know what it will be for pax failure ? [02:24] <pappy-> pipacs: can you follow me? [02:24] <pipacs> EACCES [02:24] <Azarah> pipacs: if so, we can return 0 if that is EACCESS [02:24] <Azarah> pipacs: and we will still have an choice between exec-shield or pax ... [02:24] <pipacs> Azarah, well, you can but you're still cheating :) [02:25] <Azarah> right, but who cares ? =) [02:25] <pappy-> pipacs: isnt the binary killed already when its trying? [02:25] <Azarah> serious now, when else will it fail with EACCESS ? [02:25] <pipacs> yeah ok, i just meant it won't save the users from chpax'ing apps that really need to generate code at runtime [02:25] <Azarah> right [02:25] <Azarah> but we just dont want ld.so to fail ... [02:25] <pipacs> eacces is returned only on unsatisfiable protection requests [02:26] <pipacs> pappy, killed when trying what ? calling mprotect won't kill the app, it will just return an error code [02:27] <pappy-> pipacs: but when it starts executing whatever code on a nonexec stack [02:27] <Azarah> Index: sysdeps/unix/sysv/linux/dl-execstack.c [02:27] <Azarah> =================================================================== [02:27] <Azarah> RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/dl-execstack.c,v [02:27] <Azarah> retrieving revision 1.3 [02:27] <Azarah> diff -u -p -r1.3 dl-execstack.c [02:27] <Azarah> --- sysdeps/unix/sysv/linux/dl-execstack.c 25 Sep 2003 23:04:12 -0000 1.3 [02:27] <Azarah> +++ sysdeps/unix/sysv/linux/dl-execstack.c 8 Nov 2003 00:26:30 -0000 [02:27] <Azarah> @@ -114,8 +114,11 @@ _dl_make_stack_executable (void) [02:27] <Azarah> page += size; [02:27] <Azarah> else [02:27] <Azarah> { [02:27] <Azarah> - if (errno != ENOMEM) /* Unexpected failure mode. */ [02:27] <Azarah> + if (errno == EACCESS) { /* PAX is enabled */ [02:27] <Azarah> + return 0; [02:27] <Azarah> + } else if (errno != ENOMEM) < /* Unexpected failure mode. */ [02:27] <Azarah> return errno; [02:27] <Azarah> + } [02:27] <Azarah> [02:27] <Azarah> if (size == GL(dl_pagesize)) [02:27] <Azarah> /* We just tried to mprotect the lowest hole page and failed. [02:27] <Azarah> [02:27] <Azarah> something like that ^^ [02:27] <pipacs> pappy, then of course it will die as before [02:28] <pipacs> Azarah, yes [02:28] <pappy-> so all we have been arguing here is Azarah putting us asleep with a single error checking line in a routine, oh yeah. [02:28] * pappy- really needs a bed. [02:29] <Azarah> pappy-: it will be more [02:29] <pappy-> pipacs: is that okay for you then? [02:29] <Azarah> for _STACK_GROWS_DOWN and _STACK_GROWS_UP [02:29] <pipacs> sure, i think that will solve it [02:29] <Azarah> i am not sure about PROT_GROWSDOWN though ? [02:29] <Azarah> same thing ? [02:29] <pipacs> er, is PT_GNU_STACK used/supported on anything but i386? [02:30] <Azarah> pipacs: all linux archs ... [02:30] <Azarah> pipacs: you will see that is the generic linux version ... [02:30] <pipacs> PROT_GROWSDOWN is something new in 2.6 i think but better add support there as well [02:30] <Azarah> ok [02:30] <pappy-> okay, lets resume what we have [02:30] <pappy-> when PaX is detected, the mprotect() of the ld.so will EACCESS on turning on the X bit in the stack page, right? [02:31] <pipacs> yes [02:32] <pappy-> good, now what Azarah did is adding to the normal execshield stack setup behaviour the PaX case, okay? [02:32] <pipacs> yup [02:32] <pappy-> is there some possibility that we report this back to the author of execshield, who happens to be a really really good friend of pipacs, given that they love and hug and kiss each other so much on the mailing lists... [02:33] <pipacs> pappy, this fix is a cheat, it's not a long-term solution for binary marking [02:33] <pappy-> or will this be a gentoo specific turnaround for keeping PaX in the game? [02:34] <pipacs> there would be another solution that you might consider [02:34] <Azarah> pappy-: temp fix until pipacs can sort something with m... out ? [02:34] <pappy-> pipacs: i dont know if i want PaX to set up PT_PAX flags, only if you deliver a better solution that is neither producing false positives nor allowing runtime toggle-around of dangerous stack execution rights. [02:34] <pipacs> you could turn pax off by default [02:34] <pipacs> and enable it only on specific apps [02:34] <pappy-> pipacs: this is not an option. [02:34] <pipacs> latter could be part of the build process or user specicied, etc [02:34] <pappy-> pipacs: you know that. [02:34] <pipacs> well, it depends [02:35] <pipacs> im not sure normal end users need it all on by defauly [02:35] <pipacs> a server is a different environment, there no doubt you want it on by default [02:35] <pappy-> i am sure normal end users who do not need it off by default would not feel good if you decide to leave it off. [02:35] <pipacs> an innocent end-user is however a different case [02:35] <pappy-> then they would not need to use it at all... [02:36] <pipacs> pappy, as i said, gentoo's ebuilds could be modified to activate pax on certain targets [02:36] <pipacs> which then would be known to work under pax [02:36] <pappy-> pipacs: haha [02:36] <pipacs> end users would not have to care about that prt [02:36] <pappy-> pipacs: i invite you to edit our ebuilds all as you like :-) [02:36] <pipacs> an emerge would give them a working and protected app [02:36] <Azarah> pappy-: ok, patch mailed [02:36] <pipacs> pappy-, i didn't say i had the time/energy for this ;P [02:37] <Azarah> pappy-: could we have a .tbz2 build for one of the suffering users to test ? [02:37] <Azarah> pappy-: one that have similar hw than you ? [02:37] <pappy-> pipacs: you know what, you keep using PaX in default protect mode, we keep dealing with the Redhat people. [02:37] <pappy-> pipacs: i think you will sleep over it and come to a good conclusion. [02:37] <pappy-> pipacs: you never disappoint me. [02:38] <pipacs> i'll need more than a few nights of sleep to cook up something ;) [02:39] <pappy-> pipacs: chpax is a way to mark a binary via ELF characteristics. [02:39] <pappy-> pipacs: you are right when you say that this was a fast solution back in the days when you invented it. [02:39] <Azarah> PT_GNU_STACK do not maybe break chpax in some way ? [02:39] <pappy-> pipacs: however, i do not believe that something like PT_GNU_STACK with all these automatisms has something to do with proper security [02:39] <Azarah> it not handling the new section ? [02:40] <pipacs> oh, speaking of chpax, i wanted to ask this: what's the thinking of using chpax to *run* apps w/ various pax features on/off? something like the 'i386' personality changing app of exec-shield does [02:40] <pappy-> pipacs: just think about grsecurity acl overriding THAT too! [02:40] <pipacs> Azarah, chpax for now uses a field in the elf header that is not used for other purposes. this is something i'd like to change though, to be more compliant w/ specs, hence PT_PAX_* [02:40] <Azarah> k [02:41] <pipacs> pappy, i didn't invent chpax btw, solar designer used chstk for the same purposes way back then [02:41] <pappy-> pipacs: even if you modify chpax and pax kernel to use PT_PAX_* instead of the unused elf header fields, this would not change my mood. [02:42] <pipacs> ok folks, me needs to sleep [02:42] <pappy-> pipacs: so even if execshield continues to use PT_GNU_STACK and pax uses PT_PAX_* whatever, the question remains: will these two concepts be interoperable: [02:43] <pappy-> Redhat using the compatible approach, backwards compatible to the normal userland, that they ONLY enable nonexec stack if all components play nice and ALLOW it [02:43] <pappy-> ALLOWING a security feature to be set [02:43] <pipacs> pappy, they can be if they add code to handle the other. the more important question will be whether you really want to mix such apps on a given system. [02:44] <pappy-> pipacs: i want to put the Azarah patch into the glibc and ensure we have proper PaX enforcement of operation [02:44] <pappy-> pipacs: operation system security begins where the execshield patch ends. [02:44] <pappy-> pipacs: this is very sad for me to recognize.
PaX is not write-protecting the stack but exec-protecting the stack automatically. a call to mprotect() the stack pages to make it executable again is leading to an EACCES triggered by the PaX kernel, which in return was not handled by the original execshield implementation in glibc, however, Azarah supplied a trick to detect PaX on the fly via handling the EACCES and thus give the ld.so the chance to not activate any executable stack for the binary via returning 0. research is underway if this directly or indirectly affects the chpax behaviour of binaries like java or other programs where stack execution is needed (what about closed source like halflife server daemon?). Alex
exec-protecting the stack - oops ? =)
This problem showing up for anybody that's not using PaX/grsec ?
Created attachment 20445 [details, diff] glibc-2.3.2-dl_execstack-PaX-support.patch Fix some type-o's.
Solar, nope, and check comment #27 from bug #32562: -- Disabling of GRKERNSEC_PAX_NOEXEC fixed it. Thanks. --
Would this fix actually fix the problem or just fail correctly?
After recompiling glibc if all goes well you will then want to emerge elfkickers gentoolkit then wget http://dev.gentoo.org/~solar/misc/elf-rebuild.sh.txt then sh elf-rebuild.sh.txt > outfile ; emerge -pv 'cat outfile | sort | uniq' This will give a list of what was broken from before and what might need to be rebuilt. After all these steps are done it should be fairly safe to use ~arch gcc-3.3.x again.
> Would this fix actually fix the problem or just fail correctly? Well Phillip, the problem is that the new glibc sources have support for exec-shield, which if you read comment #2, you will see is not compadible with PaX, as it tries to make the stack executable _after_ PaX have exec-proteced it. We thus have 2 choices: 1) Take out exec-shield support (which is not a good idea, as we will always have users that will want to use it) 2) Fix glibc's exec-shield support to work with Pax. Now, for 2) it is a bit difficult, as PaX cannot be detected runtime (I may be wrong here), so we change _dl_make_stack_executable() to return 0 on EACCES, as the only thing that should make it fail, should be PaX being enabled. So yes, _dl_make_stack_executable() will 'fail correctly' if PaX is enabled, as we assume that nobody will be so silly as to have both PaX and exec-shield enabled at the same time.
Martin, Well so far I have built a patched glibc with pax enabled and have unmasked and merged gcc-3.3.x and have successfully rebuilt a few things including openssl on a PaX enabled system.
*** Bug 32409 has been marked as a duplicate of this bug. ***
*** Bug 31313 has been marked as a duplicate of this bug. ***
*** Bug 32765 has been marked as a duplicate of this bug. ***
Ok, great, working on a new glibc with this, pappy's stuff, and the security updates.
As I see it's committed into portage. It works great yes (although I wasn't able to test it at first as the HD crashed), the re-install from stage3 had the same problem.
Seems safe to close this array of bugs now. In PaX/grsec 2.4.23 we now have kernel level program header support for the PT_GNU_STACK that will enable trampoline if the program flags are requesting an executable bit when mprotection is enabled. In addition support for PT_GNU_HEAP was added that will disable mprotect if the executable bit is set.
azarah, Can we close this one now?
Sure.
I am unfortunately still plagued by this bug on an Alpha. I had started from a stage 3 but couldn't get very far as several things were borking with "cannot enable executable stack as shared object requires". I've just started over with a stage 1 but during emerge system it fails on groff. In the config.log: ./conftest: error while loading shared libraries: libstdc++.so.5: cannot enable executable stack as shared object requires: Error 14 I'm doing this install chroot'ed on an existing Red Hat install (relatively old, I might add.) Since it's running kernel 2.4.3 I was wondering whether it might have something to do with the problem. I see that people with similar bugs said that using newer kernels on e.g. Knoppix solved it for them. Here's the output of "emerge info": Portage 2.0.50-r1 (default-alpha-1.4, gcc-3.3.2, glibc-2.3.2-r1,2.3.2-r9, 2.4.3-12) ================================================================= System uname: 2.4.3-12 alpha EV68AL Gentoo Base System version 1.4.3.13 Autoconf: Automake: ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=ev67 -pipe" CHOST="alphaev67-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=ev67 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache" GENTOO_MIRRORS="ftp://137.215.113.154 http://ftp.up.ac.za/mirrors/gentoo.org/gentoo/ ftp://ftp.is.co.za/linux/distributions/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://ftp.up.ac.za/gentoo-portage" USE="X aalib acpi alpha arts berkdb crypt cups encode ev6 fbcon foomaticdb gd gif ginac gpm gtk gtk2 gtkhtml imlib jikes jpeg kde libg++ libwww maildir mbox mikmod motif mozilla mpeg mpi mysql ncurses nls oggvorbis opengl oss pam pdflib perl plotutils png python qt quicktime readline samba sdl slang slp spell ssl tcltk tcpd tetex tiff truetype usb vim-with-x xml xml2 xmms xv zlib"
Hi. I have still this error while installation gentoo-hardened (but I had this error also while normal gentoo installation). I try to install gentoo from chroot of debian woody with kernel 2.4.18 and there is this error while emerge system. When I add "-Wa,--execstack" to CFLAGS in /etc/make.conf, the system will build fine, but then, when I try to configure kernel with make menuconfig, it parse config file and then nothing-I have found, that if it tries to start lxdialog, it crashes with "./scripts/lxdialog/lxdialog: error while loading shared libraries: libncurses.so.5: cannot enable executable stack as shared object requires: Error 14". Can someone please tell me, what's wrong and how could I install gentoo from debian? (I'm updating to sarge with newer kernel right now, and then I will try it with newer kernel, but as I remember, I had the same problem when installing from Knoppix).
New test in chroot of debian sarge with kernel 2.4.26-1 works fine. Probably the problem is when installing in chroot from some distro with old kernel (2.4.18). Can anyone check this error again?
Robert, Sounds like you need to reboot into a kenrel that does not have pax support in it till you complete your install. I have no idea if the problems your having are related to your glibc from the deb side of things or not. But rest assured this has been fixed in gentoo and you can run all proper like.
*** Bug 94656 has been marked as a duplicate of this bug. ***
Seeing this bug with chroot from 2.4.10 SuSE kernel. Never mind.
