On Tue, 4 Nov 2003 [EMAIL PROTECTED] 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