grsecurity forums

I've just seen the possibility of storing pax flags in extended attributes in 3.1.8. That looks excellent, and would perhaps solve my problem with chromium not working with paxctl -C I mentioned in the firefox thread.

However, which flags should have which values? Also, it seems the directories containing the files need the sticky bit set...

Carlos Carvalho wrote:I've just seen the possibility of storing pax flags in extended attributes in 3.1.8. That looks excellent, and would perhaps solve my problem with chromium not working with paxctl -C I mentioned in the firefox thread.

However, which flags should have which values?

first of all, the xattr control method is still experimental, so things can still change in the future but if you feel adventurous, you can try it like this: setfattr -n user.pax.flags -v "me" /path/to/binary will turn off MPROTECT and EMUTRAMP on the given binary (EMUTRAMP has to be added because PT_PAX_FLAGS disables it by default too and the two markings must enable/disable the same PaX features). the values you can store in user.pax.flags are the same ones that paxctl reports as well, except for x/X which the xattr control method doesn't understand (as it's an obsolete PaX feature).

Also, it seems the directories containing the files need the sticky bit set...

uhm, the user xattr namespace is accessible to the file owner without restrictions.

PaX Team wrote:you can try it like this: setfattr -n user.pax.flags -v "me" /path/to/binary will turn off MPROTECT and EMUTRAMP on the given binary (EMUTRAMP has to be added because PT_PAX_FLAGS disables it by default too and the two markings must enable/disable the same PaX features).

I understand that the contents of user.pax.flags are just the options that would be passed to paxctl, plus the defaults like clearing emutramp. I'll try it with the next program that chokes...

Also, it seems the directories containing the files need the sticky bit set...

uhm, the user xattr namespace is accessible to the file owner without restrictions.

Exactly. If the file is to be executed by different users (eg. firefox) those that are not the owner won't have access to the extended user attributes unless the directory is sticky.

Carlos Carvalho wrote:If the file is to be executed by different users (eg. firefox) those that are not the owner won't have access to the extended user attributes unless the directory is sticky.

that's not how the user namespace works . as the manpage says: The access permissions for user attributes are defined by the file permission bits. i.e., the executing user needs read access to the file in order to be able to read user.pax.flags (as a consequence, mode 711 files can't use this xattr scheme, this is something i could override for user.pax.flags, i haven't made up my mind yet). the restriction you mention applies only to executables stored in directories with the sticky bit set, i don't think that situation matters in real life (but if there's some realistic use case, i can again relax the access rights of user.pax.flags).

Yes, I misuderstood the man page.

I've applied it to 3 programs and it's working fine. I didn't change the others that were modified by paxctl -m, and all work.

Thanks for it all.