On 07/15/2011 02:44 AM, Michał Górny wrote:
> On Thu, 14 Jul 2011 19:19:11 -0400
> Mike Frysinger <[email protected]> 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 : [email protected]
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
