CAPABILITIES(7) Linux Programmer's Manual CAPABILITIES(7)
NAME
capabilities - overview of Linux capabilities
DESCRIPTION
For the purpose of performing permission checks, traditional Unix
implementations distinguish two categories of processes: privileged
processes (whose effective user ID is 0, referred to as superuser or
root), and unprivileged processes (whose effective UID is non-zero).
Privileged processes bypass all kernel permission checks, while unpriv-
ileged processes are subject to full permission checking based on the
process's credentials (usually: effective UID, effective GID, and sup-
plementary group list).
Starting with kernel 2.2, Linux provides an (as yet incomplete) system
of capabilities, which divide the privileges traditionally associated
with superuser into distinct units(1,7) that can be independently enabled
and disabled.
Capabilities List
As at Linux 2.6.6, the following capabilities are implemented:
CAP_CHOWN
Allow arbitrary changes to file(1,n) UIDs and GIDs (see chown(1,2)(2)).
CAP_DAC_OVERRIDE
Bypass file(1,n) read(2,n,1 builtins), write(1,2), and execute permission checks. (DAC =
"discretionary access(2,5) control".)
CAP_DAC_READ_SEARCH
Bypass file(1,n) read(2,n,1 builtins) permission checks and directory read(2,n,1 builtins) and exe-
cute permission checks.
CAP_FOWNER
Bypass permission checks on operations that normally require the
file(1,n) system UID of the process to match the UID of the file(1,n)
(e.g., chmod(1,2)(2), utime(2)), excluding those operations covered
by the CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH; set(7,n,1 builtins) extended
file(1,n) attributes (see chattr(1)) on arbitrary files; set(7,n,1 builtins) Access
Control Lists (ACLs) on arbitrary files; ignore directory sticky
bit on file(1,n) deletion.
CAP_FSETID
Don't clear(1,3x,3x clrtobot) set-user-ID and set-group-ID bits when a file(1,n) is
modified; permit setting of the set-group-ID bit for a file(1,n)
whose GID does not match the file(1,n) system or any of the supple-
mentary GIDs of the calling process.
CAP_IPC_LOCK
Permit memory locking (mlock(2), mlockall(2), mmap(2), shm-
ctl(2)).
CAP_IPC_OWNER
Bypass permission checks for operations on System V IPC objects.
CAP_KILL
Bypass permission checks for sending signals (see kill(1,2,1 builtins)(2)).
This includes use of the KDSIGACCEPT ioctl.
CAP_LEASE
(Linux 2.4 onwards) Allow file(1,n) leases to be established on
arbitrary files (see fcntl(2)).
CAP_LINUX_IMMUTABLE
Allow setting of the EXT2_APPEND_FL and EXT2_IMMUTABLE_FL
extended file(1,n) attributes (see chattr(1)).
CAP_MKNOD
(Linux 2.4 onwards) Allow creation of special files using
mknod(1,2)(2).
CAP_NET_ADMIN
Allow various network-related operations (e.g., setting privi-
leged socket(2,7,n) options, enabling multicasting, interface configu-
ration, modifying routing tables).
CAP_NET_BIND_SERVICE
Allow binding to Internet domain reserved socket(2,7,n) ports (port
numbers less(1,3) than 1024).
CAP_NET_BROADCAST
(Unused) Allow socket(2,7,n) broadcasting, and listening multicasts.
CAP_NET_RAW
Permit use of RAW and PACKET sockets.
CAP_SETGID
Allow arbitrary manipulations of process GIDs and supplementary
GID list; allow forged GID when passing socket(2,7,n) credentials via
Unix domain sockets.
CAP_SETPCAP
Grant or remove any capability in(1,8) the caller's permitted capa-
bility set(7,n,1 builtins) to or from any other process.
CAP_SETUID
Allow arbitrary manipulations of process UIDs (setuid(2),
setreuid(2), setresuid(2), setfsuid(2)); allow forged UID when
passing socket(2,7,n) credentials via Unix domain sockets.
CAP_SYS_ADMIN
Permit a range of system administration operations including:
quotactl(2), mount(2,8)(2), umount(2), swapon(2,8)(2), swapoff(2),
sethostname(2), setdomainname(2), IPC_SET and IPC_RMID opera-
tions on arbitrary System V IPC objects; perform operations on
trusted and security Extended Attributes (see attr(1,5)(5)); allow
forged UID when passing socket(2,7,n) credentials; exceed
/proc(5,n)/sys/fs/file-max limit in(1,8) system calls that open(2,3,n) files
(e.g., accept(2,8)(2), execve(2), open(2,3,n)(2), pipe(2,8)(2))
CAP_SYS_BOOT
Permit calls to reboot(2).
CAP_SYS_CHROOT
Permit calls to chroot(1,2)(2).
CAP_SYS_MODULE
Allow loading and unloading of kernel modules; allow modifica-
tions to capability bounding set(7,n,1 builtins) (see init_module(2) and
delete_module(2)).
CAP_SYS_NICE
Allow raising process nice(1,2) value (nice(1,2)(2), setpriority(2)) and
changing of the nice(1,2) value for arbitrary processes; allow set-
ting of real-time scheduling policies for calling process, and
setting scheduling policies and priorities for arbitrary pro-
cesses (sched_setscheduler(2), sched_setparam(2)); set(7,n,1 builtins) CPU
affinity for arbitrary processes (sched_setaffinity()).
CAP_SYS_PACCT
Permit calls to acct(2,5)(2).
CAP_SYS_PTRACE
Allow arbitrary processes to be traced using ptrace(2)
CAP_SYS_RAWIO
Permit I/O port operations (iopl(2) and ioperm(2)); access(2,5)
CAP_SYS_RESOURCE
Permit: use of reserved space on ext2 file(1,n) systems; ioctl(2)
calls controlling ext3 journaling; disk quota(1,8) limits to be over-
ridden; resource limits to be increased (see setrlimit(2));
RLIMIT_NPROC resource limit to be overridden; msg_qbytes limit
for a message queue(1,3) to be raised above the limit in(1,8)
/proc(5,n)/sys/kernel/msgmnb (see msgop(2) and msgctl(2).
CAP_SYS_TIME
Allow modification of system clock(3,n) (settimeofday(2), stime(2),
adjtimex(2)); allow modification of real-time (hardware) clock(3,n)
CAP_SYS_TTY_CONFIG
Permit calls to vhangup(2).
Process Capabilities
Each process has three capability sets containing zero or more of the
above capabilities:
Effective:
the capabilities used by the kernel to perform permission checks
for the process.
Permitted:
the capabilities that the process may assume (i.e., a limiting
superset for the effective and inheritable sets). If a process
drops a capability from its permitted set(7,n,1 builtins), it can never re-
acquire that capability (unless it execs a set-UID-root pro-
gram).
Inherited:
the capabilities preserved across an execve(2).
In the current implementation, a process is granted all permitted and
effective capabilities (subject to the operation of the capability
bounding set(7,n,1 builtins) described below) when it execs a set-UID-root program, or
if(3,n) a process with a real UID of zero execs a new program.
A child created via fork(2) inherits copies of its parent's capability
sets.
Using capset(2), a process may manipulate its own capability sets, or,
if(3,n) it has the CAP_SETPCAP capability, those of another process.
Capability bounding set(7,n,1 builtins)
When a program is execed, the permitted and effective capabities are
ANDed with the current value of the so-called capability bounding set(7,n,1 builtins),
defined in(1,8) the file(1,n) /proc(5,n)/sys/kernel/cap-bound. This parameter can be
used to place a system-wide limit on the capabilities granted to all
subsequently executed programs. (Confusingly, this bit mask parameter
is expressed as a signed decimal number in(1,8) /proc(5,n)/sys/kernel/cap-bound.)
Only the init process may set(7,n,1 builtins) bits in(1,8) the capability bounding set(7,n,1 builtins);
other than that, the superuser may only clear(1,3x,3x clrtobot) bits in(1,8) this set.
On a standard system the capability bounding set(7,n,1 builtins) always masks out the
CAP_SETPCAP capability. To remove this restriction, modify the defini-
tion of CAP_INIT_EFF_SET in(1,8) include/linux/capability.h and rebuild the
kernel.
Current and Future Implementation
A full implementation of capabilities requires:
1. that for all privileged operations, the kernel check whether the
process has the required capability in(1,8) its effective set.
2. that the kernel provide system calls allowing a process's capabil-
ity sets to be changed and retrieved.
3. file(1,n) system support for attaching capabilities to an executable
file(1,n), so that a process gains those capabilities when the file(1,n) is
execed.
As at Linux 2.6.6, only the first two of these requirements are met.
Eventually, it should be possible to associate three capability sets
with an executable file(1,n), which, in(1,8) conjunction with the capability sets
of the process, will determine the capabilities of a process after an
exec(3,n,1 builtins):
Allowed:
this set(7,n,1 builtins) is ANDed with the process's inherited set(7,n,1 builtins) to determine
which inherited capabilities are permitted to the process after
the exec.
Forced:
the capabilities automatically permitted to the process, regard-
less(1,3) of the process's inherited capabilities.
Effective:
those capabilities in(1,8) the process's new permitted set(7,n,1 builtins) are also
to be set(7,n,1 builtins) in(1,8) the new effective set. (F(effective) would nor-
mally be either all zeroes or all ones.)
In the meantime, since the current implementation does not support file(1,n)
capability sets, during an exec:
1. All three file(1,n) capability sets are initially assumed to be cleared.
2. If a set-UID-root program is being execed, or the real user ID of
the process is 0 (root) then the file(1,n) allowed and forced sets are
defined to be all ones (i.e., all capabilities set(7,n,1 builtins)).
3. If a set-UID-root program is being executed, then the file(1,n) effec-
tive set(7,n,1 builtins) is defined to be all ones.
During an exec(3,n,1 builtins), the kernel calculates the new capabilities of the
process using the following algorithm:
P'(permitted) = (P(inherited) & F(allowed)) | (F(forced) & cap_bset)
P'(effective) = P'(permitted) & F(effective)
P'(inherited) = P(inherited) [i.e., unchanged]
where:
P denotes the value of a process capability set(7,n,1 builtins) before the exec(3,n,1 builtins)
P' denotes the value of a capability set(7,n,1 builtins) after the exec(3,n,1 builtins)
F denotes a file(1,n) capability set(7,n,1 builtins)
cap_bset is the value of the capability bounding set.
NOTES
The libcap package provides a suite of routines for setting and getting
process capabilities that is more comfortable and less(1,3) likely to change
than the interface provided by capset(2) and capget(2).
CONFORMING TO
No standards govern capabilities, but the Linux capability implementa-
tion is based on the withdrawn POSIX 1003.1e draft standard.
BUGS
There is as yet no file(1,n) system support allowing capabilities to be
associated with executable files.
SEE ALSO
capget(2), prctl(2)
Linux 2.6.6 2004-05-27 CAPABILITIES(7)