#### Test case #### A simple test case for this would be to run the following as root, on a system running a capability-enabled 2.6 kernel (either through the default commoncap, or the capability LSM with CONFIG_SECURITY and CONFIG_SECURITY_CAPABILITIES) : sysctl kernel.cap-bound=0xfffefeff (drop CAP_SYS_MODULE) modprobe <some module> That works on gentoo, since processes under uid 0 keep a full capability set no matter what cap-bound says. On other distributions (and on gentoo with the fix proposed in this mail), it shows the expected behavior of not permitting module insertion. This can be verified with 'cat /proc/self/status' as root, which on Gentoo shows all three capability sets (CapInh, CapPrm, and CapEff) at 0xfffffeff (the full set, i.e. everything except CAP_SET_PCAP which is disabled by the kernel), and this holds true whatever cap-bound may be set to. Same goes for setuid-root executables launched by any non-privileged user. #### Impact #### As I said earlier, this is not really a vulnerability, and shouldn't have any impact on desktop systems (where cap-bound isn't much use, as CAP_SYS_RAWIO is needed for X11). It might however be an issue for hardened servers, where it is highly recommended to drop CAP_SYS_MODULE and CAP_SYS_RAWIO at least, as a protection against kernel-level rootkits (see e.g. what happened to the Debian servers in 2003, and how it could have been prevented : http://www.wiggy.net/debian/developer-securing/ ). Since Gentoo voids this protection (without documenting it, as far as I can tell), such systems might be at risk. #### Analysis #### The culprit for this unexpected Gentoo behavior is a patch to sys-apps/sysvinit (tested here on versions 2.86-r3 through -r5), that was applied based on bug #5818 in the gentoo bugzilla. The patch, sysvinit-2.86-POSIX-1003.1e.patch, has init set its inheritable capability to its current effective capability (which is the full set as defined in include/linux/capability.h, 0xfffffeff on 2.6 kernels). This is then inherited by all processes spawned by init, whether root or not, since the inheritable capability is never modified by the kernel (see cap_emulate_setxuid() in security/commoncap.c in the kernel source tree : only the effective and permitted sets are cleared on setuid()). Looking at cap_bprm_apply_creds() in security/commoncap.c in the kernel source shows that when exec'ing a new binary, the new effective capability is E(c) = E(b) <i> [ ( P(b) <i> cap-bound ) <u> ( I(b) <i> I(c) ) ] where E(),P(),I() denote the Effective, Permitted, and Inheritable capability sets of (c) the Current task or (b) the executed Binary, and <i> is for Intersection (bitwise AND) and <u> for Union (bitwise OR). The intersection of inherited capabilities completely bypasses the cap-bound limit. This is correct with regards to the POSIX capability model, and is supposed to provide a way for file-attached capabilities to work. However, such file capabilities are not supported by Linux, which thus sets I(b) to CAP_FULL_SET if either the current task is executing as root or the binary is setuid root (see cap_bprm_set_security() in security/commoncap.c), and 0 otherwise. Once again this is expected, documented behavior, and works correctly as long as I(c) is 0, which is supposed to be the case (see the definition of CAP_INIT_INH_SET in include/linux/capability.h). Gentoo's patch to init, however, wreaks havoc with this logic, and completely bypasses the capability bounding set mechanism as it is supposed to work in Linux. #### Fix #### Simply removing the sysvinit-2.86-POSIX-1003.1e.patch fixes this strange behavior, with no negative impact as far as I can tell. This seems the best fix, as the patch does not do anything useful (again, as far as I can tell, please correct me if I'm wrong). Short of that, a strong warning in the ebuild and in online docs would be appreciated, and possibly a USE flag to selectively disable the patch.
Got this report earlier today. Solar/Vapier could you have a look?
i have no problems punting said patch if, by design, the desired behavior cannot be obtained at this time
Adding reporter.
SpanKY, do you want confirmation from another team member or are you going to drop the patch?
sysvinit-2.86-r7 no longer applies the patch
Thx Vapier. Is 2.86-r6 ready to be marked stable?
Bah, is r6 or r7 ready for stable marking?
sysvinit-2.86-r7 is being moved to stable already for unrelated reasons, so if you wanted to push it that'd be fine ...
(In reply to comment #12) > sysvinit-2.86-r7 is being moved to stable already for unrelated reasons, so if > you wanted to push it that'd be fine ... > Hi Mike, this bug has been waiting for a long time now, i don't think it worth pushing -r7 into stable for security purpose, and given that -r6 doesn't apply the patch now. It was just about a Posix consistency, hardly a security issue. Vincent, feel free to disclose that bug by unchecking the below boxes as soon as you want (or when the bug is totally resolved).
sysvinit -r7 is now marked stable on most arches (except Alpha and AMD64). Now opening this bug with the agreement of Vincent, original reporter. I'll close it when Alpha and AMD64 mark stable >=sysvinit-2.86-r7
cc'ing those two arches - I can't find a bug for sysvinit-2.86-r7 stabilization, so I suspect that it is related to other packages. Alpha and amd64 - any word on what is blocking this stabilization? Thanks.
-7 and -8 stable on amd64, sorry about the delay...
ok so closing now with noglsa. Feel free to reopen if you disagree.
