[gentoo-dev] Automagic pax-mark

[gentoo-dev] Automagic pax-mark

[Chí-Thanh Christopher Nguyễn]

Hello All,

After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
longer has a || die. This means that the resulting binaries may have PT_PAX,
XATTR_PAX, both or neither markings depending on kernel configuration,
filesystem and mount options.

I'd say that is not a good thing. If you agree with me, what could be done
here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
would probably require pax-mark calls to be conditional on pax_kernel USE
flag or similar.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Automagic pax-mark

[Mike Gilbert]

On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Hello All,
>
> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
> longer has a || die. This means that the resulting binaries may have PT_PAX,
> XATTR_PAX, both or neither markings depending on kernel configuration,
> filesystem and mount options.
>
> I'd say that is not a good thing. If you agree with me, what could be done
> here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
> would probably require pax-mark calls to be conditional on pax_kernel USE
> flag or similar.
>

Most ebuilds do not call pax-mark || die. Most people do not run PaX
systems, so a failure here is not a major issue.

I would like to see the kernel patch enabling user.pax attributes on
tmpfs submitted to Linus' kernel tree; that would eliminate the major
cause of failures here.

In the mean time, maybe we could disable XATTR_PAX markings by default
for people not using the hardened profile.

Re: [gentoo-dev] Automagic pax-mark

[Anthony G. Basile]

On 04/07/2013 05:20 PM, Mike Gilbert wrote:
> On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> Hello All,
>>
>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>> XATTR_PAX, both or neither markings depending on kernel configuration,
>> filesystem and mount options.
>>
>> I'd say that is not a good thing. If you agree with me, what could be done
>> here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
>> would probably require pax-mark calls to be conditional on pax_kernel USE
>> flag or similar.
>>
> Most ebuilds do not call pax-mark || die. Most people do not run PaX
> systems, so a failure here is not a major issue.
>
> I would like to see the kernel patch enabling user.pax attributes on
> tmpfs submitted to Linus' kernel tree; that would eliminate the major
> cause of failures here.
>
> In the mean time, maybe we could disable XATTR_PAX markings by default
> for people not using the hardened profile.
>
You can disable either or both type of pax markings by setting 
PAX_MARKINGS.  We can change the default in the eclass.  Its currently 
set to "PT XT".  Setting it to "PT" would revert to only doing PT_PAX 
markings.  Then users will have to manually set XT in their make.conf.

I can try to get the user.pax on tmpfs patch into the Linux tree. At the 
very least, we can get it into gentoo-sources.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Automagic pax-mark

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Sun, 07 Apr 2013 18:08:41 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> I can try to get the user.pax on tmpfs patch into the Linux tree. At
> the very least, we can get it into gentoo-sources.

What does this patch do? I haven't been following this discussion;
also, please CC kernel@gentoo.org when you report this so we can track. 

On a side note, stabilization in the 3.8 branch is not far away; I am
expecting this to happen somewhere in the second half of this month. If
you want the patch to be present in the stabilized 3.8 branch kernel, it
would be nice to have the patch before then.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Automagic pax-mark

[Anthony G. Basile]

On 04/07/2013 07:01 PM, Tom Wijsman wrote:
> On Sun, 07 Apr 2013 18:08:41 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>
>> I can try to get the user.pax on tmpfs patch into the Linux tree. At
>> the very least, we can get it into gentoo-sources.
> What does this patch do? I haven't been following this discussion;
> also, please CC kernel@gentoo.org when you report this so we can track.
>
> On a side note, stabilization in the 3.8 branch is not far away; I am
> expecting this to happen somewhere in the second half of this month. If
> you want the patch to be present in the stabilized 3.8 branch kernel, it
> would be nice to have the patch before then.
>
Currently tmpfs only supports XATTR_SECURITY and XATTR_TRUSTED 
namespaces.  Take a look at mm/shmem.c, particularly 
shmem_xattr_validate() around line 2112.  But we're putting XATTR_PAX 
markings in the user namespace, actually a subspace of it, "user.pax".  
Since we need to preserve XATTR_PAX flags as portage moves stuff around, 
we need to expand the allowed xattr namespace for tmpfs.  That's what 
this patch does.

I originally wanted in gentoo-sources, but there was concern --- I 
forget who.  Pushing it upstream may be hard because upstream doesn't 
respect PaX.  I can still try.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Automagic pax-mark

[Chí-Thanh Christopher Nguyễn]

Mike Gilbert schrieb:
>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>> XATTR_PAX, both or neither markings depending on kernel configuration,
>> filesystem and mount options.
>>
>> I'd say that is not a good thing. If you agree with me, what could be done
>> here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
>> would probably require pax-mark calls to be conditional on pax_kernel USE
>> flag or similar.
>>
> Most ebuilds do not call pax-mark || die. Most people do not run PaX
> systems, so a failure here is not a major issue.

I agree that not having the pax-mark is not a significant problem
currently. It could become one when PaX becomes more widespread, but
that is not likely in the near term.

What I think is bad is the automagic aspect of enabling pax-mark.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Automagic pax-mark

[Rafael Goncalves Martins]

On Mon, Apr 8, 2013 at 9:29 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Mike Gilbert schrieb:
>>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
>>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>>> XATTR_PAX, both or neither markings depending on kernel configuration,
>>> filesystem and mount options.
>>>
>>> I'd say that is not a good thing. If you agree with me, what could be done
>>> here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
>>> would probably require pax-mark calls to be conditional on pax_kernel USE
>>> flag or similar.
>>>
>> Most ebuilds do not call pax-mark || die. Most people do not run PaX
>> systems, so a failure here is not a major issue.
>
> I agree that not having the pax-mark is not a significant problem
> currently. It could become one when PaX becomes more widespread, but
> that is not likely in the near term.
>
> What I think is bad is the automagic aspect of enabling pax-mark.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

I had some issues with pax-mark failling to work on openvz containers
stored on partitions mounted without the user_xattr argument and
ebuilds with '|| die', and was going to open bugs to people remove the
'|| die' statements from the ebuilds, when I saw this thread.

Disable xattr isn't a very common use case, but it is still valid. I
don't want to have my builds falling at install phase just because the
binary can't be pax-mark'ed, when I clearly don't care about PaX.

If we don't want the automagic behavior, we should allow users to
explicitly disable it.

--
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Automagic pax-mark

[Michael Haubenwallner]

On 04/08/2013 12:08 AM, Anthony G. Basile wrote:
> On 04/07/2013 05:20 PM, Mike Gilbert wrote:
>> On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
>> <chithanh@gentoo.org> wrote:
>>> Hello All,
>>>
>>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
>>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>>> XATTR_PAX, both or neither markings depending on kernel configuration,
>>> filesystem and mount options.

Although not used to PaX in general, I've fixed a bug report[1] where "pax-mark -c" was
sufficient to get some prebuilt thirt-party binary to run on user's hardened machine.

>> In the mean time, maybe we could disable XATTR_PAX markings by default
>> for people not using the hardened profile.
>>
> You can disable either or both type of pax markings by setting PAX_MARKINGS.
> We can change the default in the eclass.  Its currently set to "PT XT".
> Setting it to "PT" would revert to only doing PT_PAX markings.
> Then users will have to manually set XT in their make.conf.

While fixing that bug I've discovered the default value of PAX_MARKINGS="PT"
(has changed to "PT XT" since), but no profile actually setting PAX_MARKINGS="none".

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.

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).

[1] https://bugs.gentoo.org/show_bug.cgi?id=456694

my 2 cents
/haubi/

Re: [gentoo-dev] Automagic pax-mark

[Mike Gilbert]

On Mon, Apr 8, 2013 at 10:21 AM, Michael Haubenwallner <haubi@gentoo.org> 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.

> 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.

Re: [gentoo-dev] Automagic pax-mark

[Anthony G. Basile]

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