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.
The hardened team might help.
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.
(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.
(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.
(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.
(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!
(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?
(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.
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?
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.
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.
Created attachment 384478 [details, diff] Remove g+w bit from $T for TPE This updated patch fixes some additional umask and mode bits.
*** Bug 459664 has been marked as a duplicate of this bug. ***
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
(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.
When I've added user "portage" to trusted users emerging works even without patch:) Did I miss something important?
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.
(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?
(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.
(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.
Great, thanks for testing and all the good info.
This is in git now: https://github.com/gentoo/portage/commit/49896208f618817f83cfe9cd9a4a1afc87ac0f4a
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
(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.
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.
Released in portage-2.2.15.
*** Bug 540052 has been marked as a duplicate of this bug. ***
