Re: [gentoo-dev] RFC: Disambiguation of "hardened" use flag and proposal for a new global flag "pax_kernel"

[Mike Frysinger]

On Friday, July 15, 2011 02:44:45 Michał Górny wrote:
> On Thu, 14 Jul 2011 19:19:11 -0400 Mike Frysinger wrote:
> > > 3) Since a hardened kernel can be configure with various flavors of
> > > "pax" or "grsec" or "selinux", there should be useflags to reflect
> > > userland needs to conform.  There already is a "selinux" flag which
> > > is set by selinux profiles. Currently we don't see a need for a
> > > "grsec" flag, however, there is a need for a "pax" global use flag
> > > which we propose calling "pax_kernel".  (If nothing else to
> > > distinguish it from app-arch/pax.)
> > >
> > > Userland binaries which will run under a pax enabled kernel may need
> > > special treatment to run, or else they'll be killed by the kernel.
> > > The best example here is an RWX mmapping.  Although the ideal case
> > > is to "fix the code" this is not always feasible and so binaries
> > > will still need markings with paxctl -m.
> >
> > if `paxctl` is installed, then i say always run `paxctl` on the
> > problematic binaries regardless of USE flags.  have the
> > hardened-sources package depend on paxctl, and then that takes care
> > of the dependency.
>
> Do we support migrating existing systems to hardened? If so, then this
> solution will leave users with a need to manually remerge pax-setting
> packages. Though, I guess, it's pretty easy to grab that package list
> on pax-utils.eclass inherit.

that's not what i was envisioning.  the paxctl dep should be in the hardened 
profile as part of the system, and the pax-utils.eclass would be unmodified.  
the eclass has logic for silently returning if paxctl is not available.
-mike