> > [...] randomization serves NO purpose in the grand scheme, it does not > > provide guaranteed protection against the PaX attack model (arbitrary > > read/write access to the address space). [...] > > there's another, practical aspect of address-space randomization which i > find to be the most important: to make worms uneconomic in network > bandwidth terms.
having non-executable pages achieves the same *and* guarantees failure (vs. the probabilistic failure/success rate of randomization), that's why i said that randomization played no role 'in the grand scheme'. the fact it's still useful these days is the consequence of our inability to effectively protect against the attack methods 2 and 3 i had referred to earlier (luckily for the defense side, existing worms have used attack method 1 but i would not rely on that in the future). > i took the 'they are broken for good' as equivalent to 'concepts flawed by > design', and 'important privilege that should be carefully managed' as a > signal of your belief that the ability to generate code should be > restricted. I do not agree with this direction. 'they are broken for good' means just that, they are no longer able to run under PaX without tagging (at least not when PaX is configured in its optimal form, that is, with non-exec pages and MPROTECT on). you're correct with what i meant by 'managed' although i think you may not like it because of the choice of my wording, not because what i meant. if i say 'we need an API to allow userland to generate code at runtime', will you still disagree with that (meaning 'disagree on principles', not the suggested implementation)? > The moment you start to 'manage' stuff that you believe is > 'broken for good' it ends up being less accessible to people. 'root for everyone!' - isn't that concept 'broken for good' (in the sense you originally interpreted it, i.e., 'flawed by design')? see, we do change systems to be able to 'manage stuff' even if that means that we'll make that stuff 'less accessible to people' (how many times do system admins have to do things on behalf of their users because said users are now not allowed to do it themselves?). so what am i getting at here? the fact that secure (heck, even just usable) systems should follow the principle of 'least privilege'. in the multi-user system case, it says (among others) that if a user does not need to have the privilege of root (read: complete system control), then he should not have it, hence we have the concept of UIDs (and capabilites, as the case may be). in the PaX memory protection case it means that if an application does not need the privilege to generate code at runtime, then it should not have it. interestingly enough, this is exactly what i say in [3] - did you read/understand it? if you did, then you should have realized that you can argue only about whether you want to follow a least privilege policy in this case, you cannot argue about how to do it because there's just one way (the memory protection concept of PaX). > I would like to see all these security technologies to show up on Joe > Average's desktop, so government-style manual need-to-know access control > just doesnt cut it. It might work if packaged very very carefully with > lots of care towards making it simple, but i see zero efforts in that > direction. i would not call [1] or [2] 'zero efforts'. > > you said a lot about what you don't agree with in PaX, what exactly > > prevented you from changing it *yourself*? what prevents *you* from > > disabling MPROTECT by default for example? > > we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did > seem to be a reasonable person with tons of experience and this matters > alot when considering patches) and the killer at that time was the 1.5 GB > VM limitation on x86. Exec-shield, as coarse as it might be, does here and > today offer quite acceptable non-executability coverage of all actual apps > we checked, and this is what counts. (Nobody puts bogus mprotect(argv) > calls into these apps to disable exec-shield so exec-shield just works.) [...] > the mprotect argument came not from my ability to enable or disable it in > PaX, but from the claim/impression that the (mprotect) tests in paxtest > constitude actual 'Vulnerabilities'. So i simply said i dont intend to > restrict mprotect semantics in exec-shield and explained my reasons for > doing so. i'm sorry that you still haven't realized what PaX/paxtest are about. PaX works against *exploit*methods* and paxtest simulates the core steps of those methods to determine to what extent they work on a given system. what you call 'bogus' again shows your misunderstanding of how one writes exploits. let's do some thinking: why did you write Exec-Shield (non-exec pages, randomization)? to make exploit methods non-working. now the question is, have you achieved that goal or not? or a bit harder question: what did you achieve exactly? my answers are below: Exec-Shield prevents existing exploits that rely on injecting/executing their own payload from working (well, more or less, there can be cases like with multithreaded apps on a non-RedHat system where such payload shows up in a writable/executable part of the address space since such does exist under Exec-Shield, unlike PaX). i'd like to stress *existing* in the above because it leads to the next question: what can you say about *future* exploits? what can you say about the *possibility* of creating exploits that circumvent Exec-Shield? you cannot make any generic claim either way because of the lack of design in Exec-Shield. you can make claims about what is needed to circumvent it, like the attacker needs to do a return-to-libc style exploit to call mmap/mprotect and elevate the executable region limit so that he can simply execute his payload just like he did so in the past. however you cannot claim whether this is possible for a given bug or not, at least not until you or someone examines the precise circumstances and determines whether it's possible or not. who's gonna do this every time a new bug becomes public? why do we even have to ask this question and waste precious human resources to answer it? see, that's the difference between PaX and everything else i know of: PaX gives you guarantees and you can sleep a bit better because you can rest assured as to what an attacker can do with a bug (in the future that 'what' will be 'nothing beyond denial of service'). you don't understand/care about such assurance - that's your personal choice but there are people who think otherwise and don't appreciate your calling PaX methods 'bogus'. > > [...] see, there're just cases when userland is plain wrong and must be > > fixed. [...] > > there's nothing wrong about an executable stack though. It's been part of > Linux ever since. the brk() managed heap has also been executable. yet you break apps that assume so (the ominous XFree86 server would also use the brk() managed heap if you were to tell malloc() to not use mmap() at all or for 'big' areas only, well beyond the default 128k. actually, for 'small' modules XFree86 does use the brk() heap). speaking of breakage, you didn't not react on Exec-Shield breaking POSIX/SUSv3 - any comments? [1] http://adamantix.org [2] http://www.gentoo.org/proj/en/hardened [3] http://pageexec.virtualave.net/docs/noexec.txt
