On 04/08/2013 01:14 PM, Mike Gilbert wrote:
On Mon, Apr 8, 2013 at 10:21 AM, Michael Haubenwallner <[email protected]> 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 : [email protected]
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
