$ rpm -qf /sbin/sucap libcap-utils-1.10-alt16 $ uname -r 2.6.24-std-def-alt6 $ Apparently, the implementation of sucap uses an operation not permitted on current kernels; for example, trying to use it when working as root: # sucap ivan root /bin/bash Caps: =ep Caps: = [debug] uid:502, real uid:502 sucaps: capsetp: Operation not permitted sucap: child did not exit cleanly. # This makes sucap useless. A possible use of the libcap utilities could be testing of programs being executed as a given user with given capabilities. (A side note: this uselessness has already been noted by other people: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439873 .) Now, there is no way for the user "root" to run a program as a given non-root user with a given set of capabilities (in order to test how it would work). The standard way that would lead to running a program as a certain non-root user with a certain set of capabilities would be to configure the file capabilities on the executable (e.g., "setcap cap_net_raw=ep /bin/ping" -- an example from http://www.friedhoff.org/posixfilecaps.html ). The user "root" can do such a configuration (or, as for ALTLinux: "could do in ALTLinux, if there were the utilities for managing POSIX file capabilities"). What my feature request is about is: How to emulate the same result without manipulating the file system? (Before actually setting the file capabilities, the user "root" might want to test how the program will run with the intended capabilities as a non-root user.) There seems to be no means available for this scenario.
I've searched the available documentation (libcap2, linux, etc.), the mailing lists, but haven't found a potential solution. Perhaps, there is an option of "capsh" (and a corresponding option in linux processes) that would enable this scenario (the utility "capsh" accompanies libcap2 -- http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ ), but that's not clear from the documentation. Simply starting a shell with special capabilities wouldn't enable the wanted scenario, because the capabilities would be "erased" on exec (if no file capabilities are pre-configured on the executed executable). This problem has already been noticed by other people, but the discussions I found didn't suggest that this was possible in the discussed versions of linux; so, they tried to push some patches into linux, and it's not clear whether this scenario ultimately became possible. The links to 2 such discussions: 1) http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html ; 2) http://lkml.org/lkml/2006/9/7/248 . 1) http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html "Re: Capabilities across execve" writes (following a discussion of a suggested patch): ----------------------- On Sat, Mar 12, 2005 at 07:21:17PM -0800, Chris Wright wrote: > * Alexander Nyberg (alexn@dsv.su.se) wrote: > > This makes it possible for a root-task to pass capabilities to > > nonroot-task across execve. The root-task needs to change it's > > cap_inheritable mask and set prctl(PR_SET_KEEPCAPS, 1) to pass on > > capabilities. > > This overloads keepcaps, which could surprise to existing users. Chris, Since you seem to be knowledgeable about the capability system, I have a question. ... I'd like to run a certain program non-root with certain capabilities only. I looked at the above two programs and stupidly thought they'd actually allow me to do this. ... ------------ My comment: So, down the line, is it possible? It's the first thing to do when testing capabilities. It's quite illogical if "capabilities across execve" is possible if we modify the filesystem, but isn't possible in a "clean" (read-only) way just through system calls. After all, the "trick" with filesystem would still result in a sequence of operations in the kernel. And the super-user "root" should be able perform those operations directly. 2) http://lkml.org/lkml/2006/9/7/248 "Re: patch to make Linux capabilities into something useful (v 0.3.1)" -- patches that are too powerful and non-compliant to the specifications, but also targeting this problem: --------- ... So in other words, it may make sense for the process to be able to say "I want these caps to persist across exec" (*1), but it shouldn't happen automatically based on the file's attributes. In any case, perhaps it would be worthwhile making this a part of a capability_plusplus module? That would be less controversial, given that I believe many people use the capability module who really just want classic setuid behavior. ... --------- My comment: One might be satisfied with even a weaker thing: "I am root, and I want these caps to persist across exec (which I'll do after setuid)". It's possible by modifying the filesystem -- setting file-capabilities; so why shouldn't it be available without modifying the filesystem?.. Actually, this could be implemented in a controllable and clear way; perhaps, there is already a way to do this in linux; but, if not, here are the details of an imagined implementation to prove that this is possible in a clear way (and to demonstrate the wanted scenario more definitely): 1) introduce a new capability in linux, like: CAP_<set keep caps across exec>. Normally, this capability is off, but is on for the conventional root. 2) introduce the corresponding "switch", controlled by, say, prctl(): PR_SET_<keep caps across exec> (analogous to PR_SET_KEEPCAPS). If it's on, the capabilities are kept across exec, if it's off, the standard rules involving intersection with file capabilities apply (as described by "Transformation of Capabilities During exec()" in the manpage "capabilities(7)"). Now, the wanted behavior (available under root) would be programmed like this: 1) we are running under root, so CAP_<set keep caps across exec> is present; 2) do PR_SET_KEEPCAPS; 3) drop extra capabilities; 4) change UID; (the capabilities, incl. the new one, CAP_<set keep caps across exec>, are kept) 5) do PR_SET_<keep caps across exec> (we have the required capability for this); 6) drop extra capabilities except for the wanted one (if any); 7) exec... (the standard rules do not apply due to PR_SET_<keep caps across exec>: the selected capabilities are kept). So, in the result, we changed UID and kept some wanted capabilities, and executed the wanted executable.
Perhaps, the "securebits" provide a solution to this feature request. A short summary I found when searching for documentation on securebits says: ------------- ... + (3) Secure management flags (securebits). + + These are only carried by tasks. These govern the way the above + credentials are manipulated and inherited over certain operations such as + execve(). They aren't used directly as objective or subjective + credentials. ... ------------- (from http://kerneltrap.org/mailarchive/linux-kernel/2008/8/6/2838844 "[PATCH 21/24] CRED: Documentation [ver #7]").
A comment I have found makes it evident that (at least on August 27, 2007) there seemed to be no solution to my feature request ("without file capabilities there was no way") -- http://kerneltrap.org/mailarchive/linux-kernel/2007/8/27/165096 "Re: [2.6 patch] remove securebits": ---------- ... That's because without file capabilities there was no way for a process to retain capabilities across exec, so not having a privileged root user was simply not workable. ... ---------- My comment: But that's not logical if the super-user "root" can't force this behavior (for example, as I said, for the purposes of testing). (Perhaps, since then, the situation has changed.)
This bug is very old. Asynchronously setting the capabilities of a distant process was un-auditable, so when we completed the capability implementation in the kernel, this feature was removed and sucap ceased to work. This was back in 2007/2008. Since then, Ambient capabilities have been invented. They provide a path for addressing the desire expressed in this bug. There is a full write up on the ways of inheriting capabilities, the good, the bad and the ugly here: https://sites.google.com/site/fullycapable/inheriting-privilege Also, some discussion of corner cases that may surprise folk is here: https://sites.google.com/site/fullycapable/why-didnt-that-work
