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

[Anthony G. Basile]

On 07/15/2011 02:44 AM, Michał Górny wrote:
> On Thu, 14 Jul 2011 19:19:11 -0400
> Mike Frysinger <vapier@g.o> 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. -mike
> 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 could be a workable solution and would avoid the extra global flag,
but there is a glitch --- see below.  This can work because all gentoo
binaries are built with the needed ELF program header (PT_PAX) anyhow,
whether they're run under a non-hardened or pax-hardened kernel.  We can
mark them where needed as if they were going to be run under a
pax-hardened kernel, and if they're run under a non-hardened kernel, the
header is ignored and no harm done.

We do support "migration to hardened" but that means migrating to
"hardened toolchain + resulting hardened binaries".  You cannot avoid an
emerge world there.  "Migrating to a hardened kernel" would mean nothing
more than compiling hardened-sources and rebooting.  If the binaries are
correctly marked when they were first built, the user should be okay
without re-emerging anything.

So, here's the glitch.  For example, in dev-lang/mono, following the
above plan, we would drop the "hardened" flag, remove

   DEPEND=" ... hardened? ( sys-apps/paxctl )"

and replace

    if use hardened ; then
        ewarn "We are disabling MPROTECT on the mono binary."
        sed '/exec/ i\paxctl -mr "$r/@mono_runtime@"' -i
"${S}"/runtime/mono-wrapper.in
    fi

with just

    ewarn "We are disabling MPROTECT on the mono binary."
    sed '/exec/ i\paxctl -mr "$r/@mono_runtime@"' -i
"${S}"/runtime/mono-wrapper.in

But this assumes that paxctl is on the user's system which is not
guaranteed unless the users has emerged hardened-sources (which will
depend on paxctl).   scanelf would have to be the replacement in such
cases because it is guaranteed to be there by the profiles.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535