Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003 spender@grsecurity.net wrote:
> [...] the main point of my argument: exec-shield=2 means enabling
> exec-shield on all binaries but the ones it is disabled for. This would
> be a secure-by-default design, and yet it's being recommended for
> "testing purposes" only? [...]
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 ;)
> [...] 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?
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. [...]
the maps file will precisely tell you what kind of protection the process
currently has - take the highest executable address. I've got a script
with which you can continuously monitor the protection status of various
apps on the system. Offenders are taken care of :-)
> [...] How about if someone mprotects a page of the stack rwx? Whoops,
> entire address space because executable.
yes. No app currently running on my box does this though.
this is one fundamental difference in the approach: instead of breaking
apps and then chpax-ing them, exec-shield lets apps tell that they are
capable of a non-exec stack.
> From your announcement:
>
> To provide as good protection as possible, there's no trampoline
> workaround in the exec-shield code - ie. exec-limit violations in the
> trampoline case are never let through. Applications that need to rely on
> gcc trampolines will have to use the per-binary ELF flag to make the
> stack executable again.
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.
it's very easy to list the app executability requirements and the current
protections in a live system, and it's easy to improve them one by one -
while still having a 100% working system.
> [...] (funny how it was never mentioned that PaX is a true per-page
> implementation, while yours is much more coarse grained...that sounds
> pretty substantial too).
under the exec-shield VM layout the only real relevance this has is on
library bss/data executability, for like 99% (or more) of the apps. But
yes, page granularity execution bits are a plus and are available on the
platforms of the future. It was not acceptable to limit the VM to 1.5GB on
x86. It's a tradeoff.
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.]
Ingo
Reply to: