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.


Reply via email to