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
signature.asc
Description: This is a digitally signed message part.
