Re: [gentoo-dev] Automagic pax-mark

[Anthony G. Basile]

On 04/08/2013 01:14 PM, Mike Gilbert wrote:
> On Mon, Apr 8, 2013 at 10:21 AM, Michael Haubenwallner <haubi@g.o> wrote:
>> Actually I've wondered if it would make more sense to default to PAX_MARKINGS="none",
>> and have the hardened profiles (or the user in make.conf) set a different value.
> That makes some sense to me. The downside is that that switching from
> vanilla gentoo to hardened would require a rebuild of all packages
> that need pax markings.

That's why I set  PAX_MARKINGS="XT PT", to avoid the downside.  We do 
have users who switch back and forth and I'll be trading one set of bugs 
for another.  As a compromise position, we can fall back to what we've 
been doing all along, that is PAX_MARKINGS="PT".  Users who want 
XATTR_PAX and set up their system to handle xattrs on all the 
filesystems can then just set PAX_MARKINGS="XT" in their make.conf.

Just to remind everyone, all elf objects built on gentoo have a 
PAX_FLAGS program header to house the flags.  Users just don't know 
about them because the vanilla kernel ignores those flags, so its pretty 
harmless to do the markings.  Its foreign binaries (ie compiled on other 
systems) that cause issues and that's why we are aiming for XATTR_PAX 
markings as the method of choice once we get all the bugs ironed out.

Let me know what you think and I'll drop down to PAX_MARKINGS="PT" in 
the eclass.

>
>> But thinking again now, I'm wondering if pax-mark should be done in pkg_preinst rather
>> than src_install - for the sake of binary merges when the build machine has different
>> PAX_MARKINGS than the target machine (no idea if that ever would happen).
> This also makes sense to me.
>

You should do XATTR_PAX markings *after* install runs.  It can be in 
src_install() or later provided it is done after the usual emake 
install.  That's because install does not copy extended attributes. 
Practically all of coreutils does (provided its compiled with xattr 
support), but not install.  I'm working on a patch and see what upstream 
has to say, but if people want to quickly fix their packages, just move 
pax-mark later.  If you can't because you need it during src_compile 
before tests, you can always pax-mark-ing twice.

I like the idea of a FEATURES="pax" but we might want to think about a 
FEATURES="security" which introduces a new phase which can do either pax 
markings or selinux markings.  We've been doing pax markings in ebuilds, 
but selinux labeling is done after most of the system is put in place, 
the appropriate sec-policy/selinux-XXX are emerged and then a global 
rlpkg is applied.  It would be nice to automate that in a src_secmark() 
phase. (Just thinking out loud.)


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA