Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 365825 - sys-apps/chpax: old style EI_PAX markings are deprecated and should be removed
Summary: sys-apps/chpax: old style EI_PAX markings are deprecated and should be removed
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 427888 365727
  Show dependency tree
 
Reported: 2011-05-03 14:07 UTC by Francisco Blas Izquierdo Riera
Modified: 2012-08-28 03:12 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Remove chpax from pax-utils eclass (pax-utils.eclass,5.64 KB, text/plain)
2011-05-03 17:20 UTC, Anthony Basile
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francisco Blas Izquierdo Riera gentoo-dev 2011-05-03 14:07:23 UTC
As things stand now pax-mark will try to set both the old EI flags (deprecated and used by chpax) and the new PT flags (used by paxctl and working). In case paxctl is not found it will use scanelf which will enable both.

This has proven to be an issue on certain packages (bug 302589 for example). So this is what I propose:

1) We document how PAX_MARKINGS works and how to use it.
2) We fix scanelf so it can set only PT or only EI flags
3) We set sensible defaults for the PAX_MARKINGS variable on most profiles (my suggestion is none on all of them and PT on hardened ones).
4) ????
5) Profit!

Reproducible: Always
Comment 1 Anthony Basile gentoo-dev 2011-05-03 14:44:32 UTC
I recommend we proceed in the following order:

1) Remove old paxtest which dep on chpax.  These do not give correct answers anyhow.

2) Fix up pax-utils.eclass, removing all chpax in favor of paxctl.

3) p.mask chpax for removal in 30 days.

4) Patch scanelf to no long touch EI_PAX flags as suggested in coment #1.

The documentation can happen at any point along the process.
Comment 2 Anthony Basile gentoo-dev 2011-05-03 15:13:41 UTC
Step 1 complete.  The tree now only has app-admin/paxtest-0.9.9-r2 where

RDEPEND=""
DEPEND="${RDEPEND}
	sys-apps/paxctl"


Also part of step 1 which I failed to mention is gradm where we have

RDEPEND=""
DEPEND="sys-devel/bison
    sys-devel/flex
    pam? ( virtual/pam )
    || ( sys-apps/paxctl sys-apps/chpax )"

for gradm-2.1.14.201005041005, gradm-2.2.0.201011061849, gradm-2.2.1.201012121738.
Comment 3 Anthony Basile gentoo-dev 2011-05-03 15:30:57 UTC
(In reply to comment #2)

> DEPEND="sys-devel/bison
>     sys-devel/flex
>     pam? ( virtual/pam )
>     || ( sys-apps/paxctl sys-apps/chpax )"
> 

Switched to just DEPEND on sys-apps/paxctl.

Okay rather than rev bump these to force those using chpax to now emerge paxctl, I went ahead and p.masked sys-apps/chpax.

Last step is the eclass.
Comment 4 Anthony Basile gentoo-dev 2011-05-03 17:20:47 UTC
Created attachment 271993 [details]
Remove chpax from pax-utils eclass

Two changes were made to the eclass:

1) I removed the chpax code.  Basically this block:

    # Try chpax, for (deprecated) EI legacy marking.
    if type -p chpax > /dev/null && hasq EI ${PAX_MARKINGS}; then
        elog "Legacy EI PaX marking -${flags}"
        _pax_list_files elog "$@"
        for f in "$@"; do
            chpax -${flags} "${f}" && continue
            fail=1
            failures="${failures} ${f}"
        done
    fi

2) Since I had to rewrite the internal documentation, I used @ECLASS markup.


Please take a look at it and let me know.
Comment 5 Gordon Malm (RETIRED) gentoo-dev 2011-05-03 18:24:02 UTC
PaX can still be configured to enforce legacy EI_PAX flags (and should, or you get no protection by default on non-PT_PAX marked binaries).  On binaries lacking PT_PAX, PaX behavior is still controlled and dictated by EI_PAX markings (as opposed to PaX-kernel always enforcing *everything* by default on PT_PAX-lacking binaries and ignoring EI_PAX flags entirely).  This means chpax is still useful, a basic example (there are more important - think users/whoever building/dropping foreign binaries you may want to inspect without actually modifying) being packages for which upstream only provides binaries (unfortunate, but mostly still work fine with some tweaks - ex. often chpax -m).  

In Hardened we have long talked about removing the chpax code from the eclass and replacing it with paxctl -C to inject PT_PAX markings (and then -m or whatever as necessary, etc).  The concern for some time was that paxctl -C may not always work/might corrupt the binary itself under some case/scenario and so it was safer to leave it as-is and use chpax.  Now much time has passed and I have never seen or heard paxctl -C actually break (as opposed to bug #302589, which is not a breakage, but self-checking) a binary.  So I am not against chpax removal from the eclass, but I would prefer replacing chpax calls in any eclasses with paxctl -C (PT_PAX injection) as necessary, followed by the equivalent paxctl commands to mark the binary as needed.

As for what prompted this entire thing - bug #302589 is really a bad example.  The solution there is simply to not call the binary-altering function.  Skype is not the first to add self-checking to their binaries and its not the fault of chpax at all (paxctl can't touch it either).  To essentially say "skype self-checks and we used chpax to modify it, therefore chpax is bad" is hitting your hand with a hammer and then blaming the hammer.  The package can/should (and I think now is) hard-masked.  FWIW, you can sometimes defeat self-checking binaries with a wrapper and then you chpax/paxctl the wrapper as necessary -- if anyone is interested in doing this for the skype package so it can be unmasked.

Overall, biggest problem point for me is removal of sys-apps/chpax, I see no reason to do this.  It is not exactly a high-maintenace package and it should be kept available.  Has it been deprecated for a long time?  Yeah, deprecated - as in not recommended, as in there is a long-time viable replacement for most scenarios and chpax is *looking to be* retired.  Problem is, IMO, there still one more step before it can be truly be retired and that requires the kernel to change.  I argue that chpax should not be removed until it no longer holds any significant ability to alter PaX functionality under any set of circumstances -- as in all EI_PAX based control-logic has been removed from PaX and PaX just default-enforces whatever you configured into your kernel on non-PT_PAX marked binaries.  As of now, the configurable functionality is still there in the PaX kernel and upstream has not done anything recently that should prompt chpax's true demise and final removal.

Thank you for all your hard work, time and consideration.
Comment 6 Gordon Malm (RETIRED) gentoo-dev 2011-05-03 18:38:05 UTC
I should've read all the way to the end of #302589 I guess. :P

So ends up paxctl -C + paxctl -m actually works in that case.  I think it must be particular to the way they are doing their (apparently insufficient - you can still modify the binary, wonder if they know this ;) self-checking.  In all my previous experiences paxctl -C would also trip up any such checking same as chpax.  So I still consider that to be the generic/wider scenario.
Comment 7 Anthony Basile gentoo-dev 2011-05-03 22:58:42 UTC
From OFTC/#grsecurity

<blueness> so to be clear, the new behavior is that if i don't have EI_PAX enabled, only PT_PAX_FLAGS, and a binary doesn't have PT_PAX set, then it defaults to on, correct?
<spender> yes

This is in place as of April 15.  So we'll leave chpax around but continue to strongly discourage its use.  At some point, when previous kernels are deprecated, there will be no reason to keep any EI_PAX stuff around.
Comment 8 Anthony Basile gentoo-dev 2011-05-05 21:22:10 UTC
Okay, there is a reason to keep chpax around, although discourage its use.  This is based on some poc I wrote on the elfix repo:

http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=summary

There I wrote mangle-paxflags which does the following:

1) no flag - report EI_PAX settings and list all the program headers
2) -p flag, if there is a PT_PAX_FLAGS program header, mark it PT_NULL
3) -f flag, take the EI_PAX markings and set them to the least secure settings pEmrXs, the opposite of the default PeMRxS, which is most secure.

I then wrote a program bad-mmap which does an RWX mmap violating MPROTECT.

On a kernel with both CONFIG_PAX_EI_PAX=y and CONFIG_PAX_PT_PAX_FLAGS=y, I find that if the elf binary is missing its PT_PAX_FLAGS program, then EI_PAX controls its pax behavior.  Since we may encounter situations like this, its still worth having chpax around.

In contrast, with a post-April 15 kernel with CONFIG_PAX_EI_PAX=n and CONFIG_PAX_PT_PAX_FLAGS=y, then EI_PAX markings are totally irrelevant.  If the elf binary is missing its PT_PAX_FLAGS program, then the kernel defaults to the most secure settings.  This is as it should be because if an attacker puts his own binaries on a box and removes the PT_PAX_FLAGS phdr, he could circumvent pax protection.

----

Okay here's how I'm proceeding:

1) I have unmasked sys-apps/chpax
2) I will continue removing chpax from ebuilds and from the eclass to discourage its use.
3) I will talk to upstream about the future of EI_PAX.  This was a hack to get pax flags into elfs, but putting them into reserved bytes of the elf header was not the best design.
Comment 9 PaX Team 2011-05-09 17:00:53 UTC
(In reply to comment #8)
> This is as it should be because if an attacker puts his own binaries on a box
> and removes the PT_PAX_FLAGS phdr, he could circumvent pax protection.

if someone can put a binary on such a system then he can also ensure that it has a PT_PAX_FLAGS header with all protections disabled...

> Okay here's how I'm proceeding:
> 
> 1) I have unmasked sys-apps/chpax
> 2) I will continue removing chpax from ebuilds and from the eclass to
> discourage its use.
> 3) I will talk to upstream about the future of EI_PAX.  This was a hack to get
> pax flags into elfs, but putting them into reserved bytes of the elf header was
> not the best design.

for me the plan was always like this: use either RBAC to control the PaX flags (doesn't need binary modification and as a consequence userland can't override the policy) or at most use the proper marking method (PT_PAX_FLAGS). it's the latter case that had been problematic in the past until i added -C to paxctl (some binary only apps didn't use to have a convertible GNU_STACK header, so -c wasn't in general good enough, less of a problem today except for apps like skype and others who self-check themselves).

on gentoo i think you could easily ensure that all installed applications have the PT_PAX_FLAGS program header, say, as part of the QA checks.
Comment 10 Anthony Basile gentoo-dev 2011-05-17 11:16:43 UTC
I'm going to go ahead and update the eclass in a few days.  Let me know if there's any more discussion on it before I do.
Comment 11 Anthony Basile gentoo-dev 2011-05-22 01:02:20 UTC
(In reply to comment #10)
> I'm going to go ahead and update the eclass in a few days.  Let me know if
> there's any more discussion on it before I do.

eclass has been updated.  The tree should now have no references to chpax.
Comment 12 Anthony Basile gentoo-dev 2012-07-24 14:02:15 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > I'm going to go ahead and update the eclass in a few days.  Let me know if
> > there's any more discussion on it before I do.
> 
> eclass has been updated.  The tree should now have no references to chpax.

With the utilities for xattr pax markings unmasked now (sys-apps/elfix), its time to consider masking/tree cleaning this again.  I'll start the process in a few days.  Given the brokenness we've endured for a while, bug #387459, I'd like to just get this out of the way.

If there are any *very good* reasons why I should not, please post.
Comment 13 Anthony Basile gentoo-dev 2012-07-27 01:49:58 UTC
+  27 Jul 2012; Anthony G. Basile <blueness@gentoo.org> package.mask:
+  sys-apps/chpax: Masked for removal in 30 days. Bug #365825
+
Comment 14 Anthony Basile gentoo-dev 2012-08-28 03:12:41 UTC
(In reply to comment #13)
> +  27 Jul 2012; Anthony G. Basile <blueness@gentoo.org> package.mask:
> +  sys-apps/chpax: Masked for removal in 30 days. Bug #365825
> +

Its off the tree.