Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 519566 - Add support for Trusted Path Execution (TPE) (fix complaints about group-writable directory)
Summary: Add support for Trusted Path Execution (TPE) (fix complaints about group-writ...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS, TESTED
: 459664 540052 (view as bug list)
Depends on:
Blocks: 484436
  Show dependency tree
 
Reported: 2014-08-10 11:14 UTC by Plüss Roland
Modified: 2019-04-26 02:44 UTC (History)
9 users (show)

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


Attachments
_post_phase_userpriv_perms: fix bug #519566 (_post_phase_userpriv_perms-fix-bug-519566.patch,1.17 KB, patch)
2014-09-07 23:36 UTC, Zac Medico
Details | Diff
Remove g+w bit from $T for TPE (Remove-g-w-bit-from-T-for-TPE-bug-519566.patch,2.72 KB, patch)
2014-09-09 20:36 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Plüss Roland 2014-08-10 11:14:30 UTC
Linked to Bug 500928 . Back then only apache has been broken due to the problem of portage dropping user priviledges while trying to execute stuff in group writeable directories which TPE "CORRECTLY" denies. The lazy solution of GenToo devs had been so far to force people to use FEATURES="-userpriv". While this worked for apache back then its not the right solution to the problem of portage misbehaving.

Fast forward to now and the problem escalated. Since some time portage totally stopped emerging any package at all turning this lazy fixed issue into a show-stopper. Only solution right now is using FEATURES="-userpriv" on all packages and that seriously can't be the right solution.

So please go and fix that problem once and for all by making portage behave properly. If portage drops priviledges and runs stuff through exec why not make sure the umask is set to 077 to prevent sane steps during emerging to never ever have a chance to mess up the permissions in connection with TPE. This won't help against broken packages messing with umask but for these bugs could be filed to fix them. But for the rest apply a sane umask to begin with so you don't have to rely on a sledghammer work-around.
Comment 1 Christian Ruppert (idl0r) archtester Gentoo Infrastructure gentoo-dev Security 2014-09-02 16:28:27 UTC
The hardened team might help.
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2014-09-02 18:21:04 UTC
I use TPE, but have made the portage user part of the group that is exempt of the TPE protections. It is a matter of validating the security risks involved and how Portage works.

Allowing Portage to work with TPE is a larger undertaking than one might think. For instance, Portage uses (C)Python, which uses libffi, which tries to create executable files in locations you don't want. TPE (and SELinux as well to be honest) prevent this from happening, but this is the design of libffi and cannot be fixed easily.

Still, it's not because it is a large undertaking that it shouldn't be looked at. So in that sense, this bug is valid. However, if the bug about using FEATURES="userpriv" then exempting Portage from the TPE protections is a possible workaround as well.
Comment 3 Jaak Ristioja 2014-09-02 18:31:32 UTC
(In reply to Plüss Roland from comment #0)
> Fast forward to now and the problem escalated. Since some time portage
> totally stopped emerging any package at all turning this lazy fixed issue
> into a show-stopper. Only solution right now is using FEATURES="-userpriv"
> on all packages and that seriously can't be the right solution.

From what version of sys-apps/portage does this regression occur? The current amd64 stable version (2.2.8-r1) of Portage seems to work fine for with most packages on my systems.
Comment 4 Plüss Roland 2014-09-02 20:00:28 UTC
(In reply to Jaak Ristioja from comment #3)
> (In reply to Plüss Roland from comment #0)
> > Fast forward to now and the problem escalated. Since some time portage
> > totally stopped emerging any package at all turning this lazy fixed issue
> > into a show-stopper. Only solution right now is using FEATURES="-userpriv"
> > on all packages and that seriously can't be the right solution.
> 
> From what version of sys-apps/portage does this regression occur? The
> current amd64 stable version (2.2.8-r1) of Portage seems to work fine for
> with most packages on my systems.
sys-apps/portage-2.2.8-r1 . There had been multiple packages causing troubles but now any package I try to compile causes this problem.
Comment 5 Jaak Ristioja 2014-09-02 20:15:00 UTC
(In reply to Plüss Roland from comment #4)
> (In reply to Jaak Ristioja from comment #3)
> > (In reply to Plüss Roland from comment #0)
> > > Fast forward to now and the problem escalated. Since some time portage
> > > totally stopped emerging any package at all turning this lazy fixed issue
> > > into a show-stopper. Only solution right now is using FEATURES="-userpriv"
> > > on all packages and that seriously can't be the right solution.
> > 
> > From what version of sys-apps/portage does this regression occur? The
> > current amd64 stable version (2.2.8-r1) of Portage seems to work fine for
> > with most packages on my systems.
> sys-apps/portage-2.2.8-r1 . There had been multiple packages causing
> troubles but now any package I try to compile causes this problem.

I've been using the stable sys-apps/portage-2.2.8-r1 since March and the app-admin/apache-tools and www-servers/apache ebuilds are the only ones I've found to be broken on my TPE-enabled servers.
Comment 6 Anthony Basile gentoo-dev 2014-09-02 21:13:21 UTC
(In reply to Plüss Roland from comment #0)
> The lazy
> solution of GenToo devs had been so far to force people to use
> FEATURES="-userpriv".

This is not the solution we came up with to the TPE problem + portage.  We got portage and TPE working together by patching python and enabling PAX_EMUTRAMP.  This fixed what SwifT described in Comment #2.  It is not a "lazy" solution, it is the correct one.  My suspicions when you say "Since some time portage totally stopped emerging any package at all turning this lazy fixed issue into a show-stopper." is that you do not have PAX_EMUTRAMP on in the kernel and did not emerge python with USE=pax_kernel.

What's happening in bug #500928 is different. It is specific to apache as far as I can tell in comment 9 of that bug.  It started with rev 1.34 of apache-2.eclass.

> So please go and fix that problem once and for all by making portage behave
> properly. 

Short of adding portage to the wheel group, which is not as unsafe as you might think since portage already does wheel-ish stuff, there isn't going to be one fix to this.  We can't guarantee what scripts build-systems might want to run and whether those directories have group writeable perms etc.  The permissions on the directories, as far as I know, come from the tarballs, and so umasking may not be as easy as you suggest below.  We may have to catch them one at a time.

> If portage drops priviledges and runs stuff through exec why not
> make sure the umask is set to 077 to prevent sane steps during emerging to
> never ever have a chance to mess up the permissions in connection with TPE.
> This won't help against broken packages messing with umask but for these
> bugs could be filed to fix them. But for the rest apply a sane umask to
> begin with so you don't have to rely on a sledghammer work-around.

I'm not sure setting the umask is the right thing to do, but I'll add portage to the cc group to see what they think.

Also, I would ask that you refrain from calling us lazy.  This is volunteer work and overworked.  We do want to fix our bugs, but help us out here.  Patches are always welcome!
Comment 7 Anthony Basile gentoo-dev 2014-09-02 21:15:15 UTC
(In reply to Jaak Ristioja from comment #5)
> (In reply to Plüss Roland from comment #4)
> > (In reply to Jaak Ristioja from comment #3)
> > > (In reply to Plüss Roland from comment #0)
> > > > Fast forward to now and the problem escalated. Since some time portage
> > > > totally stopped emerging any package at all turning this lazy fixed issue
> > > > into a show-stopper. Only solution right now is using FEATURES="-userpriv"
> > > > on all packages and that seriously can't be the right solution.
> > > 
> > > From what version of sys-apps/portage does this regression occur? The
> > > current amd64 stable version (2.2.8-r1) of Portage seems to work fine for
> > > with most packages on my systems.
> > sys-apps/portage-2.2.8-r1 . There had been multiple packages causing
> > troubles but now any package I try to compile causes this problem.
> 
> I've been using the stable sys-apps/portage-2.2.8-r1 since March and the
> app-admin/apache-tools and www-servers/apache ebuilds are the only ones I've
> found to be broken on my TPE-enabled servers.

What workaround have you been using?
Comment 8 Anthony Basile gentoo-dev 2014-09-02 21:21:57 UTC
(In reply to Anthony Basile from comment #7)
> (In reply to Jaak Ristioja from comment #5)
> > (In reply to Plüss Roland from comment #4)
> > > (In reply to Jaak Ristioja from comment #3)
> > > > (In reply to Plüss Roland from comment #0)
> > > > > Fast forward to now and the problem escalated. Since some time portage
> > > > > totally stopped emerging any package at all turning this lazy fixed issue
> > > > > into a show-stopper. Only solution right now is using FEATURES="-userpriv"
> > > > > on all packages and that seriously can't be the right solution.
> > > > 
> > > > From what version of sys-apps/portage does this regression occur? The
> > > > current amd64 stable version (2.2.8-r1) of Portage seems to work fine for
> > > > with most packages on my systems.
> > > sys-apps/portage-2.2.8-r1 . There had been multiple packages causing
> > > troubles but now any package I try to compile causes this problem.
> > 
> > I've been using the stable sys-apps/portage-2.2.8-r1 since March and the
> > app-admin/apache-tools and www-servers/apache ebuilds are the only ones I've
> > found to be broken on my TPE-enabled servers.
> 
> What workaround have you been using?

Sorry for the noise, but your comment #12 in bug #500928 is the correct solution here and should just be added to the eclass intelligently.  Users should not be forced into discovering `FEATURES="-userpriv" emerge apache` or adding portage to wheel by themselves.

@spanky, can't we just add `chmod 700 "${T}"` just before line 444 in http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/apache-2.eclass?r1=1.34&r2=1.35  But I'm not sure it won't break something else.
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-09-07 16:47:26 UTC
Apache isn't the only thing  bitten by g+w on $T; sys-block/fio does as well (it's NOT an autoconf, but rather a custom configure):
[784189.531121] grsec: From 24.85.140.46: denied untrusted exec (due to file in group-writable directory) of /var/tmp/portage/sys-block/fio-2.0.14-r1/temp/fio-conf-12560-9054-10123.exe by /var/tmp/portage/sys-block/fio-2.0.14-r1/temp/fio-conf-12560-9054-10123.exe[configure:9086] uid/euid:250/250 gid/egid:250/250, parent /var/tmp/portage/sys-block/fio-2.0.14-r1/work/fio-2.0.14/configure[configure:9054] uid/euid:250/250 gid/egid:250/250

Does the portage team have any objects to Portage setting $T to g-w?
Comment 10 Zac Medico gentoo-dev 2014-09-07 22:48:06 UTC
A function called _post_phase_userpriv_perms adds the g+w bit so that files written in a phase with root privileges (like pkg_setup) can still be written in a later phase that runs as the "portage" user.

This behavior can likely be removed without causing any problems for most (if not all) ebuilds.
Comment 11 Zac Medico gentoo-dev 2014-09-07 23:36:46 UTC
Created attachment 384380 [details, diff]
_post_phase_userpriv_perms: fix bug #519566

Grant permissions to the portage user instead of the group, in order
to avoid TPE complaints about the g+w bit.
Comment 12 Zac Medico gentoo-dev 2014-09-09 20:36:05 UTC
Created attachment 384478 [details, diff]
Remove g+w bit from $T for TPE

This updated patch fixes some additional umask and mode bits.
Comment 13 Zac Medico gentoo-dev 2014-09-15 18:49:12 UTC
*** Bug 459664 has been marked as a duplicate of this bug. ***
Comment 14 Marcin Mirosław 2014-09-16 09:38:56 UTC
I just tried Zac's patch. It seems it doesn't work for me. After patching portage-2.2.8-r1 (on live fileystsem) emerging stops with the same error:

/usr/lib64/portage/bin/phase-helpers.sh: ./configure: /bin/sh: bad interpreter: Permission denied 

from dmesg:
[80669.769020] grsec: From 192.168.2.1: denied untrusted exec (due to not being in trusted group and file in non-root-owned directory) of /var/tmp/portage/dev-db/postgresql-base-9.2.9/work/postgresql-9.2.9/configure by /var/tmp/portage/dev-db/postgresql-base-9.2.9/work/postgresql-9.2.9/configure[ebuild.sh:22102] uid/euid:250/250 gid/egid:250/250, parent /usr/lib64/portage/bin/ebuild.sh[ebuild.sh:22070] uid/euid:250/250 gid/egid:250/250
Comment 15 Zac Medico gentoo-dev 2014-09-16 16:27:30 UTC
(In reply to Marcin Mirosław from comment #14)
It looks like you need to trust the "portage" user, because the configure phase is supposed to execute as the "portage" user when FEATURES=userpriv is enabled.
Comment 16 Marcin Mirosław 2014-09-17 11:08:25 UTC
When I've added user "portage" to trusted users emerging works even without patch:) Did I miss something important?
Comment 17 Sean Santos 2014-09-17 16:11:13 UTC
GRKERNSEC_TPE_ALL and GRKERNSEC_TPE are actually different restrictions and both have to be dealt with. You have to put portage in a trusted group for the latter, but for the former, you also need changes mentioned here.

If you don't use TPE_ALL, this bug doesn't apply to you.
Comment 18 Zac Medico gentoo-dev 2014-10-07 19:31:38 UTC
(In reply to Sean Santos from comment #17)
> GRKERNSEC_TPE_ALL and GRKERNSEC_TPE are actually different restrictions and
> both have to be dealt with. You have to put portage in a trusted group for
> the latter, but for the former, you also need changes mentioned here.
> 
> If you don't use TPE_ALL, this bug doesn't apply to you.

Can we get someone who's familiar with all these subtle details to test the attached patch and let us know if it works as intended?
Comment 19 Anthony Basile gentoo-dev 2014-10-07 22:01:44 UTC
(In reply to Zac Medico from comment #18)
> (In reply to Sean Santos from comment #17)
> > GRKERNSEC_TPE_ALL and GRKERNSEC_TPE are actually different restrictions and
> > both have to be dealt with. You have to put portage in a trusted group for
> > the latter, but for the former, you also need changes mentioned here.
> > 
> > If you don't use TPE_ALL, this bug doesn't apply to you.
> 
> Can we get someone who's familiar with all these subtle details to test the
> attached patch and let us know if it works as intended?

Hi Zac.  This patch works as expected.  I applied it to portage-2.2.8-r2.  I got the expected failure before and success after.

To be very clear what's going on here, comment #17 is critical.  You must have the following:

i686-hardened-gdb portage # zcat /proc/config.gz | grep TPE
CONFIG_GRKERNSEC_TPE_UNTRUSTED_GID=100
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
# CONFIG_GRKERNSEC_TPE_INVERT is not set
CONFIG_GRKERNSEC_TPE_GID=100

With TPE_ALL on we have the following restrictions (from the help):

CONFIG_GRKERNSEC_TPE_ALL:

If you say Y here, all non-root users will be covered under
a weaker TPE restriction.  This is separate from, and in addition to,
the main TPE options that you have selected elsewhere.  Thus, if a
"trusted" GID is chosen, this restriction applies to even that GID.
Under this restriction, all non-root users will only be allowed to
execute files in directories they own that are not group or
world-writable, or in directories owned by root and writable only by
root.  If the sysctl option is enabled, a sysctl option with name
"tpe_restrict_all" is created.

Note carefully the statement "Thus, if a trusted GID is chosen, this restriction applies to even that GID. ... all non-root users will only be allowed to execute files in directories they own that are not group or
world-writable,"

I too was confused from comment #1 which did not point out the *ALL*  This leads one to think the solution as I described it in comment #9 is sufficient.  Even a careful reading of bug #500928 doesn't make it clear that its a TPE vs TPE_ALL difference.

Thanks Sean Santos for noticing this and pointing this out.
Comment 20 Anthony Basile gentoo-dev 2014-10-07 22:03:18 UTC
(In reply to Anthony Basile from comment #19)

> I too was confused from comment #1 which did not point out the *ALL* 

I mean comment #0.
Comment 21 Zac Medico gentoo-dev 2014-10-07 22:24:00 UTC
Great, thanks for testing and all the good info.
Comment 23 Chris Henhawke 2014-11-01 10:34:58 UTC
Is there a version of portage in the tree that has this patch included?  I'm getting the apache error in bug 500928, and would like to test so I can upgrade it.  Thanks
Comment 24 Zac Medico gentoo-dev 2014-11-01 11:38:48 UTC
(In reply to Chris Henhawke from comment #23)
> Is there a version of portage in the tree that has this patch included?

Nothing except portage-9999, for now.
Comment 25 Sean Santos 2014-12-11 09:26:08 UTC
Looks like this is in 2.2.15, so whenever that is stable I think that this bug will be done. There will still be packages that run things in other problematic directories (not just ${T}), but those will probably have to be dealt with on a case-by-case basis in whichever ebuilds have issues.
Comment 26 Brian Dolbec gentoo-dev 2015-02-15 05:31:02 UTC
Released in portage-2.2.15.
Comment 27 Zac Medico gentoo-dev 2015-02-23 22:09:40 UTC
*** Bug 540052 has been marked as a duplicate of this bug. ***