mkcapx creates a capx stub file. A capx stub file is an executable file that causes another executable file to be executed in its place, but with possibly different Linux capabilities. A capx stub file effectively implements the file capabilities that are part of the POSIX capabilities model.
To be a valid capx stub, you install the file that mkcapx creates as setuid and owned by uid 0.
mkcapx /bin/ping -progname=/bin/ping.priv \ -permitted=net_raw -effective=net_raw
mkcapx
-progname=name
[-permitted=capability_list]
[-effective=capability_list]
[-inheritable=capability_list]
Examples of capability_list:
chown
sys_admin,sys_module
!sysadmin,sys_module
This ! means "all capabilities except." Remember to escape this in a shell command
An empty string means no capabilities. A lone exclamation point (!) means all capabilities.
Minimum unique abbreviation of option is acceptable. You may use double hyphens instead of single hyphen to denote options. You may use white space in place of the equals sign to separate an option name from its value.
For capx stub files to be useful, you must have a kernel that contains the capx executable interpreter. You can load that as loadable kernel module (LKM) binfmt_capx. If you don't have that interpreter in your kernel, Linux will not recognize a capx stub file as a valid executable file.
The -progname option identifies the program to run. This gives the absolute path name of a file that is in some executable format recognized by the system, for example ELF or Bourne shell script. Note that using a capx stub file, you can install a shell script to run with privileges, which is something you can't do with a setuid flag.
The -progname option is mandatory.
The program you specify gets execed with the same arguments, including arg 0, with which you invoked the capx stub file.
The -permitted, -inheritable, and -effective options determine, respectively, the permitted, inheritable, and effective capability sets of the file to be executed. Each of these sets defaults to the empty set. See File Capability Sets.
To perform an IP ping, a process needs the NET_RAW capability, which allows the process to see all network packets sent to the system. An ordinary user cannot generally be given this capability, because then he could see much more than just the ICMP echo replies that he is entitled to see. The ping program ignores all packets except those ICMP echo replies, so as long as the ping program is running, it is OK for the process to have NET_RAW capability.
The classic Unix solution to this problem is to make /bin/ping setuid superuser. Then the process has not only NET_RAW, but every privilege available in the system, while it is running the ping program. The problem with this is that a bug in the ping program could be a disastrous security exposure.
Using file capabilities instead, you can make the process have only the NET_RAW capability while it is running ping. That way, the worst that can happen if there is a bug in the ping program is that someone can see network packets he shouldn't.
To set that up, install the ping program as /bin/ping.priv, without the setuid flag. Then install a capx stub file as /bin/ping with the setuid flag and owned by uid 0.
Create the aforementioned capx stub file like this, as root:
mkcapx /bin/ping -progname=/bin/ping.priv \ -permitted=net_raw -effective=net_raw chmod a+rx /bin/ping
To test mkcapx (or your understanding of it), specify -progname=cat and use it to display the /proc/PID/status file. That file shows all of a process' capabilities.
mkcapx catwithcaps -progname=/bin/cat -permitted='!chown' capxprint catwithcaps chmod u+x catwithcaps ./catwithcaps /proc/self/status
You don't need any special permissions to create a capx stub file. For it to be useful, though, you need to be able to set its owning uid to 0 and its setuid flag on. One way to be permitted to do this is to have effective uid 0. Another way is to have the DAC_OVERRIDE capability.
To run a capx stub, you must have permission to execute the file, via file permissions, or the DAC_OVERRIDE capability.
mkcapx itself has no security considerations; all it does is format some information. But having the capx stub file interpreter in your kernel and installing capx stub files have serious security considerations.
First of all, note that anyone who can install a valid capx stub file can take over a system.
Capx stub files give special privilege to uid 0, because having an owner uid of 0 is what identifies a capx stub file as valid. While uid 0 being special is nothing new in classic Unix, a system using Linux capabilities is usually thought not to give special meaning to uid 0 -- i.e. it does not have a superuser.
To limit the chance of someone illicitly creating or modifiying a capx stub file, consider mounting a filesystem that contains a capx stub file read-only. Mount filesystems that don't need to contain capx stub files with the NOSUID mount option. Restrict the SYS_ADMIN capability, which allows a process to change mount options.
If you can't use restrictive mount options this way, then you need to be aware that the risk of someone illicitly getting uid 0 or the DAC_OVERRIDE capability is the risk of someone getting every privilege in the system.
The three capability sets of a file, along with the three preexisting capability sets of the process, determine the three capability sets of the process after it execs the file.
With mkcapx's defaults of empty sets for all three file capability sets, after execing the file, the process has no permitted, inheritable, or effective capabilities.
If you exec a file directly instead of via a capx stub file, the file's capabilities are determined by its setuid flag and whether or not the owner of the file is uid 0.
A file's permitted and inheritable capability sets affect the process' permitted and inheritable capability sets after exec. A file's effective capability set affects the process' effective capability set after exec.
The permitted capabilities of a file are in the process' permitted capability set after exec regardless of the process' capabilities before exec. The file's permitted capability set performs the function of a setuid superuser program in conventional Unix.
A file's inheritable capability allows a capability to remain in the permitted capability set after exec if that capability was already a permitted capability. If a process has inheritable capability X, which implies it also has permitted capability X, and the file it execs has inheritable capability X too, the process will continue to have permitted capability X after exec.
The methods described in the preceding paragraphs are the only ways a capability can end up in a process' permitted capability set after exec. Any capability that is not in the file's permitted or inheritable capability set will not be in the process' permitted set after exec.
The effective capabilities of a file become the effective capabilities of the process after exec, except that the process does not have any effective capabilities that are not then in its permitted capability set.
After exec, a process' inheritable capability set is identical to its permitted capability set.
Use capxprint to display the contents of a capx stub file.
Another way to run a program with specific capabilities is to use capexec. capexec is a program that execs another program you specify with capabilities that you specify. It also lets you choose user and group information for the process. capexec cannot add privilege as a capx stub file can, but it can drop privilege. If you install it setuid superuser, the combination can allow a process to add privilege.
To change the capabilities of a process without that process doing an exec, use capset.
You can see the capabilities a process currently has with capget.