From ${URL} : Common Vulnerabilities and Exposures assigned an identifier CVE-2014-3215 to the following vulnerability: Name: CVE-2014-3215 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3215 Assigned: 20140503 Reference: http://openwall.com/lists/oss-security/2014/04/29/7 Reference: http://openwall.com/lists/oss-security/2014/04/30/4 Reference: http://openwall.com/lists/oss-security/2014/05/08/1 seunshare in policycoreutils 2.2.5 is owned by root with 4755 permissions, and executes programs in a way that changes the relationship between the setuid system call and the getresuid saved set-user-ID value, which makes it easier for local users to gain privileges by leveraging a program that mistakenly expected that it could permanently drop privileges. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Again seunshare vulnerability? Oh boy; thanks for the heads-up, I'm right on it
We only install if USE="sesandbox" is set up, which isn't done by default. I'll go through the technical discussion and see what the safest approach is to take.
Okay, there are currently some mitigations already in place. If you are running our SELinux policy in enforcing mode, and the users are *not* unconfined_t, then the SELinux policy prevents seunshare to work anyway. Apparently the tool (provided by RedHat) is meant to be run by unconfined users. By default, SELinux uses the strict policies. Second, disabling SELinux controls (or running in permissive) still doesn't work. I have yet to find out why (seunshare exits if it can't drop its privileges, for some reason on my systems that is triggered and the exploit fails). Might be grsecurity related, although I cannot confirm this. Anyway, the fix by RedHat is two-fold: libcap-ng first needs to be fixed (seems to be in libcap-ng-0.7.4 although RedHat's first attempt at fixing this failed, I have yet to see if Gentoo's libcap-ng-0.7.4 has the fix. There is a second update in seunshare ready, which I'll look into now.
I'm going to drop sesandbox support (and seunshare) altogether. It doesn't work on Gentoo for quite a few releases apparently, we don't provide the policy and there's actually little use for it.
policycoreutils-2.2.5-r4 and policycoreutils-2.3_rc1-r1 are now available in the tree, ~arch for now, which do not support USE="sesandbox" anymore. Added elog's to the ebuild that the support has been removed, writing up blogpost for this as well. Stabilization of policycoreutils-2.2.5-r4 will be done soon, servers are running regression tests currently.
Please advise when ready for stabilization.
Tests were successful. The policycoreutils-2.2.5-r4 package is now stabilized.
Just an update, the userland 2.3 stuff has gone stable now so we can probably start removing the vulnerable ones soon. See bug: 514194
yes, we can.
Vulnerable versions are no longer in the tree
CVE-2014-3215 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3215): seunshare in policycoreutils 2.2.5 is owned by root with 4755 permissions, and executes programs in a way that changes the relationship between the setuid system call and the getresuid saved set-user-ID value, which makes it easier for local users to gain privileges by leveraging a program that mistakenly expected that it could permanently drop privileges.
Arches and Maintainer(s), Thank you for your work. New GLSA Request filed.
This issue was resolved and addressed in GLSA 201412-44 at http://security.gentoo.org/glsa/glsa-201412-44.xml by GLSA coordinator Yury German (BlueKnight).
