On 22 Dec 2012 at 12:13, Anthony G. Basile wrote: > http://dev.gentoo.org/~blueness/zzz/pax-quickstart.xml > > It describes pretty much anything. Give it a read and let me know what > you think should be added.
some notes: > Note that if you enable both PT_PAX and XATTR_PAX, then the kernel expects > both fields to be identical, otherwise neither field is respected. this is almost true ;). what the kernel expects is that if *both* methods are enabled in the kernel config *and* set on the userland binaries then they have to be identical. notably this leaves the possibility to *not* specify the user.pax.flags xattrs at all on the binaries yet still enable XATTR_PAX support in the kernel safely: such binaries will simply run with the highest protection by default, much like in the old days of EI_PAX. this also means that there's no chicken and egg problem despite what this says: > [...]but now we have a chicken and the egg problem: we don't have XATTR_PAX > markings on our ELF objects, but we're asking the kernel to respect them. you can safely disable PT_PAX support in the kernel and enable only XATTR_PAX and the resulting system will run all your binaries with the most secure settings (i.e., with non-exec pages, mprotect and aslr enabled). you'll only have to set xattrs on the binaries where some of these have to be relaxed (mprotect on java, etc), i.e., all this migration should *not* blindly set user.pax.flags on all userland binaries but only on those that need something disabled (or in case of emutramp, enabled). i believe this makes the whole migration much easier.