1CAPABILITIES(7) Linux Programmer's Manual CAPABILITIES(7)
2
6 capabilities - overview of Linux capabilities
7
9 For the purpose of performing permission checks, traditional Unix
10 implementations distinguish two categories of processes: privileged
11 processes (whose effective user ID is 0, referred to as superuser or
12 root), and unprivileged processes (whose effective UID is non-zero).
13 Privileged processes bypass all kernel permission checks, while unpriv‐
14 ileged processes are subject to full permission checking based on the
15 process's credentials (usually: effective UID, effective GID, and sup‐
16 plementary group list).
17 Starting with kernel 2.2, Linux divides the privileges traditionally
19 associated with superuser into distinct units, known as capabilities,
20 which can be independently enabled and disabled. Capabilities are a
21 per-thread attribute.
22 Capabilities List
24 As at Linux 2.6.14, the following capabilities are implemented:
25 CAP_AUDIT_CONTROL (since Linux 2.6.11)
27 Enable and disable kernel auditing; change auditing filter
28 rules; retrieve auditing status and filtering rules.
29 CAP_AUDIT_WRITE (since Linux 2.6.11)
31 Allow records to be written to kernel auditing log.
32 CAP_CHOWN
34 Allow arbitrary changes to file UIDs and GIDs (see chown(2)).
35 CAP_DAC_OVERRIDE
37 Bypass file read, write, and execute permission checks. (DAC =
38 "discretionary access control".)
39 CAP_DAC_READ_SEARCH
41 Bypass file read permission checks and directory read and exe‐
42 cute permission checks.
43 CAP_FOWNER
45 Bypass permission checks on operations that normally require the
46 file system UID of the process to match the UID of the file
47 (e.g., chmod(2), utime(2)), excluding those operations covered
48 by the CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH; set extended
49 file attributes (see chattr(1)) on arbitrary files; set Access
50 Control Lists (ACLs) on arbitrary files; ignore directory sticky
51 bit on file deletion; specify O_NOATIME for arbitrary files in
52 open(2) and fcntl(2).
53 CAP_FSETID
55 Don't clear set-user-ID and set-group-ID bits when a file is
56 modified; permit setting of the set-group-ID bit for a file
57 whose GID does not match the file system or any of the supple‐
58 mentary GIDs of the calling process.
59 CAP_IPC_LOCK
61 Permit memory locking (mlock(2), mlockall(2), mmap(2), shm‐
62 ctl(2)).
63 CAP_IPC_OWNER
65 Bypass permission checks for operations on System V IPC objects.
66 CAP_KILL
68 Bypass permission checks for sending signals (see kill(2)).
69 This includes use of the KDSIGACCEPT ioctl.
70 CAP_LEASE
72 (Linux 2.4 onwards) Allow file leases to be established on
73 arbitrary files (see fcntl(2)).
74 CAP_LINUX_IMMUTABLE
76 Allow setting of the EXT2_APPEND_FL and EXT2_IMMUTABLE_FL
77 extended file attributes (see chattr(1)).
78 CAP_MKNOD
80 (Linux 2.4 onwards) Allow creation of special files using
81 mknod(2).
82 CAP_NET_ADMIN
84 Allow various network-related operations (e.g., setting privi‐
85 leged socket options, enabling multicasting, interface configu‐
86 ration, modifying routing tables).
87 CAP_NET_BIND_SERVICE
89 Allow binding to Internet domain reserved socket ports (port
90 numbers less than 1024).
91 CAP_NET_BROADCAST
93 (Unused) Allow socket broadcasting, and listening multicasts.
94 CAP_NET_RAW
96 Permit use of RAW and PACKET sockets.
97 CAP_SETGID
99 Allow arbitrary manipulations of process GIDs and supplementary
100 GID list; allow forged GID when passing socket credentials via
101 Unix domain sockets.
102 CAP_SETPCAP
104 Grant or remove any capability in the caller's permitted capa‐
105 bility set to or from any other process.
106 CAP_SETUID
108 Allow arbitrary manipulations of process UIDs (setuid(2),
109 setreuid(2), setresuid(2), setfsuid(2)); allow forged UID when
110 passing socket credentials via Unix domain sockets.
111 CAP_SYS_ADMIN
113 Permit a range of system administration operations including:
114 quotactl(2), mount(2), umount(2), swapon(2), swapoff(2),
115 sethostname(2), setdomainname(2), IPC_SET and IPC_RMID opera‐
116 tions on arbitrary System V IPC objects; perform operations on
117 trusted and security Extended Attributes (see attr(5)); call
118 lookup_dcookie(2); use ioprio_set(2) to assign IOPRIO_CLASS_RT
119 and IOPRIO_CLASS_IDLE I/O scheduling classes; perform keyctl(2)
120 KEYCTL_CHOWN and KEYCTL_SETPERM operations. allow forged UID
121 when passing socket credentials; exceed /proc/sys/fs/file-max,
122 the system-wide limit on the number of open files, in system
123 calls that open files (e.g., accept(2), execve(2), open(2),
124 pipe(2); without this capability these system calls will fail
125 with the error ENFILE if this limit is encountered); employ
126 CLONE_NEWNS flag with clone(2) and unshare(2); perform
127 KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2) operations.
128 CAP_SYS_BOOT
130 Permit calls to reboot(2) and kexec_load(2).
131 CAP_SYS_CHROOT
133 Permit calls to chroot(2).
134 CAP_SYS_MODULE
136 Allow loading and unloading of kernel modules; allow modifica‐
137 tions to capability bounding set (see init_module(2) and
138 delete_module(2)).
139 CAP_SYS_NICE
141 Allow raising process nice value (nice(2), setpriority(2)) and
142 changing of the nice value for arbitrary processes; allow set‐
143 ting of real-time scheduling policies for calling process, and
144 setting scheduling policies and priorities for arbitrary pro‐
145 cesses (sched_setscheduler(2), sched_setparam(2)); set CPU
146 affinity for arbitrary processes (sched_setaffinity(2)); set I/O
147 scheduling class and priority for arbitrary processes
148 (ioprio_set(2)); allow migrate_pages(2) to be applied to arbi‐
149 trary processes and allow processes to be migrated to arbitrary
150 nodes; allow move_pages(2) to be applied to arbitrary processes;
151 use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2).
152 CAP_SYS_PACCT
154 Permit calls to acct(2).
155 CAP_SYS_PTRACE
157 Allow arbitrary processes to be traced using ptrace(2)
158 CAP_SYS_RAWIO
160 Permit I/O port operations (iopl(2) and ioperm(2)); access
161 /proc/kcore.
162 CAP_SYS_RESOURCE
164 Permit: use of reserved space on ext2 file systems; ioctl(2)
165 calls controlling ext3 journaling; disk quota limits to be over‐
166 ridden; resource limits to be increased (see setrlimit(2));
167 RLIMIT_NPROC resource limit to be overridden; msg_qbytes limit
168 for a message queue to be raised above the limit in
169 /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2).
170 CAP_SYS_TIME
172 Allow modification of system clock (settimeofday(2), stime(2),
173 adjtimex(2)); allow modification of real-time (hardware) clock
174 CAP_SYS_TTY_CONFIG
176 Permit calls to vhangup(2).
177 Capability Sets
179 Each thread has three capability sets containing zero or more of the
180 above capabilities:
181 Effective:
183 the capabilities used by the kernel to perform permission checks
184 for the thread.
185 Permitted:
187 the capabilities that the thread may assume (i.e., a limiting
188 superset for the effective and inheritable sets). If a thread
189 drops a capability from its permitted set, it can never re-
190 acquire that capability (unless it exec()s a set-user-ID-root
191 program).
192 inheritable:
194 the capabilities preserved across an execve(2).
195 A child created via fork(2) inherits copies of its parent's capability
197 sets. See below for a discussion of the treatment of capabilities dur‐
198 ing exec().
199 Using capset(2), a thread may manipulate its own capability sets, or,
201 if it has the CAP_SETPCAP capability, those of a thread in another
202 process.
203 Capability bounding set
205 When a program is execed, the permitted and effective capabilities are
206 ANDed with the current value of the so-called capability bounding set,
207 defined in the file /proc/sys/kernel/cap-bound. This parameter can be
208 used to place a system-wide limit on the capabilities granted to all
209 subsequently executed programs. (Confusingly, this bit mask parameter
210 is expressed as a signed decimal number in /proc/sys/kernel/cap-bound.)
211 Only the init process may set bits in the capability bounding set;
213 other than that, the superuser may only clear bits in this set.
214 On a standard system the capability bounding set always masks out the
216 CAP_SETPCAP capability. To remove this restriction (dangerous!), mod‐
217 ify the definition of CAP_INIT_EFF_SET in include/linux/capability.h
218 and rebuild the kernel.
219 The capability bounding set feature was added to Linux starting with
221 kernel version 2.2.11.
222 Current and Future Implementation
224 A full implementation of capabilities requires:
225 1. that for all privileged operations, the kernel check whether the
227 thread has the required capability in its effective set.
228 2. that the kernel provide system calls allowing a thread's capability
230 sets to be changed and retrieved.
231 3. file system support for attaching capabilities to an executable
233 file, so that a process gains those capabilities when the file is
234 execed.
235 As at Linux 2.6.14, only the first two of these requirements are met.
237 Eventually, it should be possible to associate three capability sets
239 with an executable file, which, in conjunction with the capability sets
240 of the thread, will determine the capabilities of a thread after an
241 exec():
242 Inheritable (formerly known as allowed):
244 this set is ANDed with the thread's inheritable set to determine
245 which inheritable capabilities are permitted to the thread after
246 the exec().
247 Permitted (formerly known as forced):
249 the capabilities automatically permitted to the thread, regard‐
250 less of the thread's inheritable capabilities.
251 Effective:
253 those capabilities in the thread's new permitted set are also to
254 be set in the new effective set. (F(effective) would normally
255 be either all zeroes or all ones.)
256 In the meantime, since the current implementation does not support file
258 capability sets, during an exec():
259 1. All three file capability sets are initially assumed to be cleared.
261 2. If a set-user-ID-root program is being execed, or the real user ID
263 of the process is 0 (root) then the file inheritable and permitted
264 sets are defined to be all ones (i.e., all capabilities enabled).
265 3. If a set-user-ID-root program is being executed, then the file
267 effective set is defined to be all ones.
268 Transformation of Capabilities During exec()
270 During an exec(), the kernel calculates the new capabilities of the
271 process using the following algorithm:
272 P'(permitted) = (P(inheritable) & F(inheritable)) |
274 (F(permitted) & cap_bset)
275 P'(effective) = P'(permitted) & F(effective)
277 P'(inheritable) = P(inheritable) [i.e., unchanged]
279 where:
281 P denotes the value of a thread capability set before the
283 exec()
284 P' denotes the value of a capability set after the exec()
286 F denotes a file capability set
288 cap_bset is the value of the capability bounding set.
290 In the current implementation, the upshot of this algorithm is that
292 when a process exec()s a set-user-ID-root program, or when a process
293 with an effective UID of 0 exec()s a program, it gains all capabilities
294 in its permitted and effective capability sets, except those masked out
295 by the capability bounding set (i.e., CAP_SETPCAP). This provides
296 semantics that are the same as those provided by traditional Unix sys‐
297 tems.
298 Effect of User ID Changes on Capabilities
300 To preserve the traditional semantics for transitions between 0 and
301 non-zero user IDs, the kernel makes the following changes to a thread's
302 capability sets on changes to the thread's real, effective, saved set,
303 and file system user IDs (using setuid(2), setresuid(2), or similar):
304 1. If one or more of the real, effective or saved set user IDs was
306 previously 0, and as a result of the UID changes all of these IDs
307 have a non-zero value, then all capabilities are cleared from the
308 permitted and effective capability sets.
309 2. If the effective user ID is changed from 0 to non-zero, then all
311 capabilities are cleared from the effective set.
312 3. If the effective user ID is changed from non-zero to 0, then the
314 permitted set is copied to the effective set.
315 4. If the file system user ID is changed from 0 to non-zero (see setf‐
317 suid(2)) then the following capabilities are cleared from the
318 effective set: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
319 CAP_FOWNER, and CAP_FSETID. If the file system UID is changed from
320 non-zero to 0, then any of these capabilities that are enabled in
321 the permitted set are enabled in the effective set.
322 If a thread that has a 0 value for one or more of its user IDs wants to
324 prevent its permitted capability set being cleared when it resets all
325 of its user IDs to non-zero values, it can do so using the prctl()
326 PR_SET_KEEPCAPS operation.
327
329 The libcap package provides a suite of routines for setting and getting
330 capabilities that is more comfortable and less likely to change than
331 the interface provided by capset(2) and capget(2).
332
334 No standards govern capabilities, but the Linux capability implementa‐
335 tion is based on the withdrawn POSIX.1e draft standard.
336
338 There is as yet no file system support allowing capabilities to be
339 associated with executable files.
340
342 capget(2), prctl(2), setfsuid(2), pthreads(7)
343Linux 2.6.18 2006-07-31 CAPABILITIES(7)