Re: [gentoo-hardened] Progress towards XATTR_PAX in Gentoo.

[Anthony G. Basile]

On 01/04/2013 08:24 PM, PaX Team wrote:
> 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:

Nice!  I did not know that.

>
>> [...]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.
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]