Re: Grsec/PaX and Exec-shield
> yes. It's a compatible opt-in for something that cannot be enabled for all
> binaries, instead of an opt-out. You say it's a bug, i say it's a feature.
> A really bad analogy: it's like spam, you want to opt-in not opt-out ;)
That is indeed a really bad analogy. Security shouldn't be as unwanted
as spam.
>
> > [...] Note that PaX enables itself on all binaries by default, and that
> > Ingo here does not argue that exec-shield=2 could result in a
> > non-working system. Basically, his following argument, which I cannot
> > refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES,
> > then it results in a working system.
>
> my main argument is that on a PT_GNU_STACK-recompiled system, you'll see
> that the overwhelming majority of binaries and libraries have a non-exec
> stack almost straight away. With some extra tweaking and patching it's up
> to 99.9%.
>
> [ or you can manually force on the feature for every binary, if you dont
> have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on
> a per binary basis, if you want/need to. ]
>
> i'm not sure why you are fighting the PT_GNU_STACK concept - it's not
> connected to exec-shield at all - just take the ELF loader bits from the
> exec-shield patch and use it in PaX - it will be for the better to get rid
> of a fair share of chpax use. (Like you changed the library layout in PaX
> to match that of exec-shield.)
>
> if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> change it to use PT_GNU_STACK to set the process stack's protection bits
> then i think there's no need for exec-shield - PaX will provide better
> protection at no cost and no tradeoffs. I did and still do exec-shield to
> solve a problem. If something else does it better with no tradeoffs then
> all the better, one less maintainance headache :-)
>
> > Now, I remember some complaining about having to chpax java if you run
> > it and PaX breaks it. How is that more work than running exec-shield in
> > =1 mode, and having to explicitly enable it on all binaries you think
> > should have protection, since you don't recommend =2 for production
> > machines?
>
> you dont have to explicitly enable it on all binaries you think should
> have protection - the compiler will do this just fine via PT_GNU_STACK. It
> is a property of the binary, not some policy question, whether an
> application needs an executable stack or not.
>
> where does PaX re-enable stack executability if an application dlopen()s a
> library that needs an executable stack - because eg. it is using gcc
> trampolines? Can you enable PaX for Mozilla and guarantee that no plugin
> will ever need an executable stack?
If a library uses trampolines, PaX doesn't need to enable stack
executability because it has trampoline emulation. I enable PaX on
mozilla and use several plugins including flash with no problems.
> java (or any other non-PT_GNU_STACK third party app) will just default to
> exec-shield-off.
>
> > Viewing the process' maps file isn't going to tell you what kind of
> > protection the process currently has. [...]
Sorry, I should have said "what protection the process had a millisecond
before you decided to check its maps file" It's this kind of "quantum
security" (while you don't observe it, it could be doing what you want
or nothing at all) that I wouldn't want as an administrator. If a
binary decides to create a mapping with some bad protections, in
PaX, the administrator would be notified. In Exec-shield, this
kind of behavior will affect the executability of sections of the address
space that were previously non-executable and the administrator might
never know, even if he had the same script as you checking processes on
the system.
> this is an old announcement, and says other things too that are not the
> case anymore. E.g. this area got reworked since then and these (rare but
> existing) apps/libs are detected automatically via the PT_GNU_STACK
> mechanism.
but is it not still true that you don't have trampoline emulation: if an
application uses trampolines the solution in exec-shield is to make the
entire stack executable?
> really, if you think granularity is a big issue for everything else but
> library bss/data then feel free to install Fedora and check out the
> mappings. It just doesnt happen all that often anymore that an app
> triggers some really bad protection layout, and if it happens, it's
> fixable in a nonintrusive way. The important thing is to have protection
> here and now for 99% of the layouts in a generic distribution. [with the
> caveat of library bss/data, as you correctly observed.]
I'm making a big issue of the granularity because you make a big issue
of the 1.5GB limit. While granularity in your case actually is an issue
for all exec-shield apps, the fact is I've received no reports of anyone
running into address space limits with PaX. So I'll agree that the
granularity in cases other than libraries isn't a huge issue, and since
you talk about generic distributions, you should also be reasonable enough
to accept that for 99% of users the address space limitation is not an
issue. grsecurity is used on hundreds of thousands of machines. I
would imagine most of them are using PaX. If you think that the address
space limitation is an issue for any more than 1% of users (and it's not
even a big issue, you can leave on just randomization if you want, or
use PAGEEXEC if you can stand the performance hit), then back it up with
some numbers of first-hand or second-hand reports.
-Brad
Reply to: