> In essence, PAX attempts a best-effort of mapping existing and unchanged > Linux binaries (except for marking) so that they are mapped best for > security. They do this by changing almost only kernel code. This is not correct. PaX is about researching various ways of protection against memory corruption bugs. The kernel land approach has just happened to be the first step, it does not mean it's the last one. And indeed, ever since we introduced full ASLR (more than 2 years ago), PaX has extended its reach into userland, since to make proper use of this, you have to create so called ET_DYN executables (a userland change, available in both Adamantix [1] and Hardened Gentoo [2] these days), and of course our userland changes do not stop here, as you can see it in the future plan documentation [3]. > W^X does not do what PAX does; rather, W^X attempts to solve many of > the same problem AREAS, but using entirely DIFFERENT SOLUTIONS. One of the PaX features ([4]) implements the least privilege policy in the context of runtime code generation (which is one of the possible ways to exploit a memory corruption bug). This is achieved by separating writable and executable pages into distinct sets (and keeping them that way, at least by default because we believe in 'secure by default'). To be able to do this separation you have to have the ability to mark pages non-executable of course (writability is not a problem). Now tell me how this is different from W^X which, err, also implements non-executable pages (for the same purpose, no less)? > Yet, persistantly we have been flooded by PAX supporters demanding > that we should give credit to the PAX people for the ideas in W^X. > When we had NOT known about PAX, and when W^X does NOT technically do > what PAX does. You keep stating that you had not known about PaX yet when asked for presenting the internal discussions you had while developing your W^X and other solutions ([5]), you suddenly go silent? Do you want to tell me that there are no mailing list archives, icb logs, etc about your technical discussions? Or are they secret? > Holy cow, can you guys please stop crowing for me to revise history! In order to revise history, one would need to know it in the first place. > It is clear that W^X was developed without knowlege of PAX; it is clear > that this is a case of two solutions to a similar problem space -- call it > convergent evolution; it is clear that begging for credit is just making > your efforts look more and more political and less and less techical. > I urge the PAX authors to get their community's rabid foaming under control. I see you have the habit of creating paper tigers then burning them hard and then thinking you're the hero of the jungle. The fact is, there is no such thing as 'our community with rabid foaming'. We're not OpenBSD after all, so there's noone to control. > In attack after attack posted to our mailing lists, we were not being asked > to say that the ideas from the PAX people predated the ideas in W^X. No, no! > We were being told to say that W^X ideas were *COPIED* from PAX, when > we had no idea that such a thing as PAX even existed! Interesting, this [5] says otherwise, where did you pull that out of, another paper tiger of yours? > Furthermore, there are difference in approach between W^X and PAX which > are so fundamental that it is clear we did not copy from PAX! I don't think anyone was questioning the origin of your *code* since there's next to no way to share such between Linux and the BSDs (at least not in the VM). > Like, our idea that mprotect should still permit a user to request a > page that is PROT_EXEC|PROT_WRITE; by default the PAX people prefer to > deny such requests. We chose that because that's the more secure way. You allow runtime code generation because there's maybe 0.1% of all applications that need it and at the same time compromise the security measures you want to provide as has been pointed out earlier in this thread (return-to-libc style attack to call mprotect() and others). I personally believe that it's better to have the best security out of the box for stuff like sshd or apache, and live with the inconvenience of having to exempt java explicitly. > If you look at the PAX web and other much more formal documentation, > you will find that they do not mention W^X. For this there is a simple explanation: i have yet to finish the documentation on related work (it will be a separate document), it's a big undertaking when you consider the almost 40 references i dug up on the net (some of which have apparently been unknown even to researchers in this area well), so i chose to write code instead. But rest assured, once it's finished, your work will be a part of it as well (at the then current level of course, not long forgotten and obsolete history as it happens in some papers). > If you look at Crispin's StackGuard papers, you will not find a > mention of ProPolice -- which is clearly a better StackGuard. Why > should we mention PAX? It does not influence what OpenBSD users > encounter. Are Linux people being specifically told "This is PAX, > like W^X in OpenBSD"? Indeed, it's not about influencing others but simple courtesy of acknowledging related work - something you have failed to do, or when you did, you made misleading statements (think of your earlier POSIX (non-)compliance claims in PaX which i see you stopped now). > W^X was invented because we saw the need for it. We had no idea > that anyone else was working in the same area. Actually i don't think this is something you should be so proud of, it means that despite your claim ("Our aspiration is to be NUMBER ONE in the industry for security") you didn't actually follow the industry and have missed out on certain developments for years. > I have seen about 50 mails from PAX developers or PAX-associated > developers or users insisting that we say that W^X is a PAX derivative. Please provide the references to these 50 emails from me or 'associated' people. > I will not revise history to make your ego feel less bruised. There is no need to revise history, just make it known/available to all. [1] http://adamantix.org/ [2] http://www.gentoo.org/proj/en/hardened/ [3] http://pageexec.virtualave.net/docs/pax-future.txt [4] http://pageexec.virtualave.net/docs/noexec.txt [5] http://marc.theaimsgroup.com/?l=openbsd-misc&m=105060386219963&w=2