Linux-Privs Andrew G. Morgan, morgan@parc.power.net DRAFT v0.10 1997/4/21 This is the specification document for Linux-Privs. It is a "standard" describing the kernel component to a secure system based around a Linux Kernel and is designed to be as compatible with POSIX.1e as is possible without open access to the actual specifications. ______________________________________________________________________ Table of Contents: . Introduction . Capabilities 1. POSIX capabilities 1.1. CAP_CHOWN 1.2. CAP_DAC_OVERRIDE 1.3. CAP_DAC_READ_SEARCH 1.4. CAP_FOWNER 1.5. CAP_FSETID 1.6. CAP_KILL 1.7. CAP_LINK_DIR 1.8. CAP_SETFCAP 1.9. CAP_SETGID 1.10. CAP_SETUID 1.11. CAP_SIGMASK 1.12. CAP_MAC_DOWNGRADE 1.13. CAP_MAC_READ 1.14. CAP_MAC_RELABEL_SUBJ 1.15. CAP_MAC_UPGRADE 1.16. CAP_MAC_WRITE 1.17. CAP_INF_NOFLOAT_OBJ 1.18. CAP_INF_NOFLOAT_SUBJ 1.19. CAP_INF_RELABEL_OBJ 1.20. CAP_INF_RELABEL_SUBJ 1.21. CAP_AUDIT_CONTROL 1.22. CAP_AUDIT_WRITE 2. Linux specific capabilities 2.1. CAP_LINUX_IMMUTABLE 2.2. CAP_LINUX_KERNELD 2.3. CAP_LINUX_INSMOD 2.4. CAP_LINUX_RMMOD 2.5. CAP_LINUX_RAWIO 2.6. CAP_LINUX_ATTENTION 2.7. CAP_LINUX_RANDOM 3. Other capabilities 3.1. CAP_NET_BIND_SERVICE 3.2. CAP_NET_BROADCAST 3.3. CAP_NET_DEBUG 3.4. CAP_NET_FIREWALL 3.5. CAP_NET_IFCONFIG 3.6. CAP_NET_PACKET 3.7. CAP_NET_RAW 3.8. CAP_NET_ROUTE 3.9. CAP_NET_SETID 3.10. CAP_IPC_LOCK 3.11. CAP_IPC_OWNER 3.12. CAP_SYS_CHROOT 3.13. CAP_SYS_PTRACE 3.14. CAP_SYS_ACCOUNT 3.15. CAP_SYS_ADMIN 3.16. CAP_SYS_BOOT 3.17. CAP_SYS_DEVICES 3.18. CAP_SYS_NICE 3.19. CAP_SYS_RESOURCE 3.20. CAP_SYS_TIME 3.21. CAP_SYS_TTY_CONFIG 3.22. CAP_SYS_QUOTA 3.22. Capability sets 4. Sets of capabilities 4.1. The capability set type 4.2. Capability set macros 4.2.1. _cap_raise(cap_value_t capability) 4.2.2. _cap_lower(cap_value_t capability); 4.2.3. _cap_raised(cap_value_t capability); 5. Filesystem capabilitiy sets 5.1. Inheritable (fI) 5.2. Permitted (fP) 5.3. Effective (fE) 6. Process/task capabilities 6.1. Effective (pE) 6.2. Inheritable (pI) 6.3. Permitted (pP) 6.3. Access Control Lists (ACL) 6.3. Mandatory Access Control (MAC) 6.3. Information Labels (IL) 6.3. Sensitivity Labels (SL) 6.3. Integrity checking; system recovery 6.3. Auditing 7. First some kernel infrastructure: 8. What audit records should contain? 9. Next some Policy (when/what should we audit): 10. User level auditing (POSIX): 11. Internal kernel auditing facility 12. Preserving the audit log 13. Auditing policy 13. Process/task credentials 13. Acknowledgements 13. Copyright/license for this document ______________________________________________________________________ 11.. IInnttrroodduuccttiioonn The Linux-Privs project is an effort to implement a POSIX.1e (formerly POSIX 6) security model under Linux. At the heart of the changes to the Linux kernel from the historical model is the separation of identity and privilege. Historically, root (UID=0) was all powerful and other users (UID!=0) had power that was limited to that associated with their identity and their group memberships. The Linux-Privs scheme is to implement a set of independent capabilities that can be given to any user. In point of fact, the capabilities are associated with applications and can only be used within the confines of the functionality of such applications. In this way individual capabilities can be restricted to a trusted set of applications. Typically, the user will have to authenticate himself to such an applciation before it will perform its privileged task. This new scheme for system privilege lends itself well to restricting privileged access to the system and reduces the risk of intruders or poorly written applications running amok on the system. 22.. CCaappaabbiilliittiieess In this chapter we list the capabilities known to the Linux Kernel. Firstly, we list the POSIX defined capabilities, and then those specific to Linux. 22..11.. PPOOSSIIXX ccaappaabbiilliittiieess Here we list the POSIX capabilities honored by Linux. 22..11..11.. CCAAPP__CCHHOOWWNN The #define for the symbol _POSIX_CHOWN_RESTRICTED, indicates that this capability (CAP_CHOWN) is known. This capability enables the current process to change the owner of a file. Generally, file ownership is not changeable by a user: it is implied by the user that creates it. 22..11..22.. CCAAPP__DDAACC__OOVVEERRRRIIDDEE The #define for the symbol __PPOOSSIIXX__AACCLL, indicates that Access Control Lists (an implementation of Discretionary Access Control) are supported by the kernel and that the following capabilities is known: CAP_DAC_OVERRIDE. This capability overrides all DAC restrictions regarding read and search on files and directories, including ACL's. 22..11..33.. CCAAPP__DDAACC__RREEAADD__SSEEAARRCCHH Overrides all restrictions about allowed operations on files, where file owner ID must be equal to the user ID, except where CAP_FSETID is applicable. It doesn't override MAC and DAC restrictions. 22..11..44.. CCAAPP__FFOOWWNNEERR Overrides the following restrictions that the effective user ID shall match the file owner ID when setting the S_ISUID and S_ISGID bits on that file; that the effective group ID (or one of the supplementary group IDs) shall match the file's group owner ID when setting the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are cleared on successful return from chown(2). 22..11..55.. CCAAPP__FFSSEETTIIDD Overrides the restriction that the real or effective user ID of a process sending a signal must match the real or effective user ID of the process receiving the signal. 22..11..66.. CCAAPP__KKIILLLL Overrides the restriction that the real or effective user ID of a process sending a signal must match the real or effective user ID of the process receiving the signal. 22..11..77.. CCAAPP__LLIINNKK__DDIIRR Overrides the restriction that a process cannot create or delete a hard link to a directory. This shall not override MAC and DAC policies. 22..11..88.. CCAAPP__SSEETTFFCCAAPP Allows the (re)setting of a files capabilities. 22..11..99.. CCAAPP__SSEETTGGIIDD Allows setgid(2) manipulation. 22..11..1100.. CCAAPP__SSEETTUUIIDD Allows setuid(2) manipulation 22..11..1111.. CCAAPP__SSIIGGMMAASSKK Overrides the restriction that no process may block SIGKILL and SIGSTOP. 22..11..1122.. CCAAPP__MMAACC__DDOOWWNNGGRRAADDEE This capability is available if _POSIX_MAC is #define'd. This capability allows a process to downgrade an object's information label. 22..11..1133.. CCAAPP__MMAACC__RREEAADD This capability is available if _POSIX_MAC is #define'd. Allows a process to override MAC read restrictions. 22..11..1144.. CCAAPP__MMAACC__RREELLAABBEELL__SSUUBBJJ This capability is available if _POSIX_MAC is #define'd. Allows a process to modify its own label. 22..11..1155.. CCAAPP__MMAACC__UUPPGGRRAADDEE This capability is available if _POSIX_MAC is #define'd. This capability allows a process to upgrade an object's information label. 22..11..1166.. CCAAPP__MMAACC__WWRRIITTEE This capability is available if _POSIX_MAC is #define'd. This capability overrides the MAC restrictions on writes. 22..11..1177.. CCAAPP__IINNFF__NNOOFFLLOOAATT__OOBBJJ This capability is available if _POSIX_INF is #define'd. This capability prevents a process' information label from floating during writes. 22..11..1188.. CCAAPP__IINNFF__NNOOFFLLOOAATT__SSUUBBJJ This capability is available if _POSIX_INF is #define'd. This capability prevents the process' information label from floating during reads or executes. 22..11..1199.. CCAAPP__IINNFF__RREELLAABBEELL__OOBBJJ This capability is available if _POSIX_INF is #define'd. This capability allows a process to change an object's information label. 22..11..2200.. CCAAPP__IINNFF__RREELLAABBEELL__SSUUBBJJ This capability is available if _POSIX_INF is #define'd. This capability allows a process to modify its own information label in violation of the overriding policy. 22..11..2211.. CCAAPP__AAUUDDIITT__CCOONNTTRROOLL This capability is available if _POSIX_AUD is #define'd. This capability allows a process to modify the audit control parameters. 22..11..2222.. CCAAPP__AAUUDDIITT__WWRRIITTEE This capability is available if _POSIX_AUD is #define'd. This capability allows a process to write data to the audit trail. 22..22.. LLiinnuuxx ssppeecciiffiicc ccaappaabbiilliittiieess This section lists additional capabilities that are specific to Linux or not covered by the POSIX capability definitions. 22..22..11.. CCAAPP__LLIINNUUXX__IIMMMMUUTTAABBLLEE Allow modification of S_IMMUTABLE and S_APPEND file attributes. 22..22..22.. CCAAPP__LLIINNUUXX__KKEERRNNEELLDD Permission to act as kerneld. 22..22..33.. CCAAPP__LLIINNUUXX__IINNSSMMOODD Allow installation of kernel modules. 22..22..44.. CCAAPP__LLIINNUUXX__RRMMMMOODD Allow removal of kernel modules. 22..22..55.. CCAAPP__LLIINNUUXX__RRAAWWIIOO Allow ioperm/iopl access. 22..22..66.. CCAAPP__LLIINNUUXX__AATTTTEENNTTIIOONN Allow configuration of the secure attention key. 22..22..77.. CCAAPP__LLIINNUUXX__RRAANNDDOOMM Allow administration of the random device. 22..33.. OOtthheerr ccaappaabbiilliittiieess This sction lists those capabilities commonly found on other systems besides Linux, but which are not specified by POSIX. 22..33..11.. CCAAPP__NNEETT__BBIINNDD__SSEERRVVIICCEE Allows binding to TCP/UDP sockets below 1024. 22..33..22.. CCAAPP__NNEETT__BBRROOAADDCCAASSTT Allow broadcasting. 22..33..33.. CCAAPP__NNEETT__DDEEBBUUGG Allow setting debug option on sockets. 22..33..44.. CCAAPP__NNEETT__FFIIRREEWWAALLLL Allow configuring of firewall stuff. 22..33..55.. CCAAPP__NNEETT__IIFFCCOONNFFIIGG Allow interface configuration. 22..33..66.. CCAAPP__NNEETT__PPAACCKKEETT Allow use of PACKET sockets. 22..33..77.. CCAAPP__NNEETT__RRAAWW Allow use of RAW sockets. 22..33..88.. CCAAPP__NNEETT__RROOUUTTEE Allow modification of routing tables. 22..33..99.. CCAAPP__NNEETT__SSEETTIIDD CAP.FIXME: what is this about?. 22..33..1100.. CCAAPP__IIPPCC__LLOOCCKK Allow locking of segments in memory. 22..33..1111.. CCAAPP__IIPPCC__OOWWNNEERR Override IPC ownership checks. 22..33..1122.. CCAAPP__SSYYSS__CCHHRROOOOTT Allow use of chroot(). 22..33..1133.. CCAAPP__SSYYSS__PPTTRRAACCEE Allow ptrace() of any process. 22..33..1144.. CCAAPP__SSYYSS__AACCCCOOUUNNTT Allow configuration of process accounting. 22..33..1155.. CCAAPP__SSYYSS__AADDMMIINN System Admin functions: mount et al. 22..33..1166.. CCAAPP__SSYYSS__BBOOOOTT Allow use of reboot(). 22..33..1177.. CCAAPP__SSYYSS__DDEEVVIICCEESS Allow device administration. 22..33..1188.. CCAAPP__SSYYSS__NNIICCEE Allow use of renice() on others, and raising of priority. 22..33..1199.. CCAAPP__SSYYSS__RREESSOOUURRCCEE Override resource limits. 22..33..2200.. CCAAPP__SSYYSS__TTIIMMEE Allow manipulation of system clock. 22..33..2211.. CCAAPP__SSYYSS__TTTTYY__CCOONNFFIIGG Allow configuration of tty devices. 22..33..2222.. CCAAPP__SSYYSS__QQUUOOTTAA Allow examination and configuration of disk quotas. 33.. CCaappaabbiilliittyy sseettss In this chapter we introduce the concept of sets of capabilities. We also discuss the way in which such sets are maintained by the kernel and their association with system objects. 33..11.. SSeettss ooff ccaappaabbiilliittiieess Capabilities are independent and an application may have any number of them raised. The total selection of raised capabilities constitutes a capability set. 33..11..11.. TThhee ccaappaabbiilliittyy sseett ttyyppee The kernel represents a capability set with the structure struct __cap_s. and may be thought of as a bitmap. The number of capability bits is currently 128. There is a special, empty, capabiltiy set. This set has no capabilities raised. 33..11..22.. CCaappaabbiilliittyy sseett mmaaccrrooss To manipulate capabilities, a kernel task uses one of the following three macros: 33..11..22..11.. __ccaapp__rraaiissee((ccaapp__vvaalluuee__tt ccaappaabbiilliittyy)) This macro raises a capability in a capability set. It is used (with respect to a capability "struct __cap_s c") in the following manner: c._cap_raise(CAP_AUDIT_CONTROL); Note, the macro is used in place of a member of the __cap_s. 33..11..22..22.. __ccaapp__lloowweerr((ccaapp__vvaalluuee__tt ccaappaabbiilliittyy));; This macro lowers a capability in a capability set. It is used (with respect to a capability "struct __cap_s c") in the following manner: c._cap_lower(CAP_AUDIT_CONTROL); Note, the macro is used in place of a member of the __cap_s. 33..11..22..33.. __ccaapp__rraaiisseedd((ccaapp__vvaalluuee__tt ccaappaabbiilliittyy));; This macro returns _t_r_u_e(!=0) if the capability is raised, and _f_a_l_s_e(=0) if the capability was lowered. It is used in the following manner: if (c._cap_raised(CAP_AUDIT_CONTROL)) { /* .... action in case that capability is raised .... */ } Note, this macro is used as if it were a member of the capability structure. 33..22.. FFiilleessyysstteemm ccaappaabbiilliittiiyy sseettss Files on the system have the following capability sets. 33..22..11.. IInnhheerriittaabbllee ((ffII)) This is the set of capabilities that the program is permitted to inherit. In this way, the program can be configured to be safe for operation with a fixed number of capabilities. (This has the feature of eliminating the total colapse of system security in the face of an insecurely written game.) 33..22..22.. PPeerrmmiitttteedd ((ffPP)) This is the set of capabilities that are explicitly raised when the new process is exec()'d. 33..22..33.. EEffffeeccttiivvee ((ffEE)) This is a single valued capability set (0 or 0) that is required to be set if the process (after an exec) is to have all of its capabilities automatically raised. It is intended to be used with programs that were written before the concept of capabilities was introduced. Newly written programs should raise their own capabilities manually. 33..33.. PPrroocceessss//ttaasskk ccaappaabbiilliittiieess Processes (also know as kernel-tasks) have the following capability sets. They are copied unchanged when the process performs a fork() (or more generally, a clone()) function call. Capability sets for a process are always affected by a call to exec(). Additionally, user level programs can manipulate their own capabilities with system calls to sys_[gs]etproccap(). Capabilities are grouped into sets and come in three forms: Effective; Inheritable; and Permitted. 33..33..11.. EEffffeeccttiivvee ((ppEE)) This is the set of capabilities that are currently _r_a_i_s_e_d, or in effect. This is set upon exec() to pE' = pP' & fE. In other words, the new effective set is the new permitted set masked with the exec()uted file's effective set.. Capabilities may be raised in the Effective set only if they are already raised in the Permitted set. Capabilities not in the Effective set are "lowered", or are inactive. 33..33..22.. IInnhheerriittaabbllee ((ppII)) This is the set of capabilities that can be passed through an exec(). These capabilities do not have to be raised in the predecessor to be passed, just present in the old process sets. Following an exec(), the Inheritable set becomes pI' = pI. Or in other words, the Inheritable set is passed unchanged thrhough and exec().. 33..33..33.. PPeerrmmiitttteedd ((ppPP)) These are the capabilities that are potentially available to the current task. Following an exec(), the process' Permitted set is constructed from the following combination of the former, and invoked, file's capability sets: pP' = fP | ( fI & pI ). Or in other words, the process' permitted set becomes the combination of the permitted set of the exec()'d file and those inheritable capabilities of the exec()ing file that are also inheritable by the file. Turning off a capability set in the Permitted set does not affect its status in the Inheritable set. The following is apparently a quote: (draft 13 of POSIX .1e) POSIX B.15.1.9 "The corresponding inheritable flag is not affected, so that privileges can be conditionally transmitted along a process chain whose intermediate processes may themselves have no privileges" (N.B. At this stage in the development of the POSIX standard, capabilities were termed privileges.) So if you want to turn off the capabilities in the Inheritable set, you should explicitly turn it off, not just turn it off in the Permitted set. 44.. AAcccceessss CCoonnttrrooll LLiissttss ((AACCLL)) 55.. MMaannddaattoorryy AAcccceessss CCoonnttrrooll ((MMAACC)) 66.. IInnffoorrmmaattiioonn LLaabbeellss ((IILL)) 77.. SSeennssiittiivviittyy LLaabbeellss ((SSLL)) 88.. IInntteeggrriittyy cchheecckkiinngg;; ssyysstteemm rreeccoovveerryy 99.. AAuuddiittiinngg An auditing facility is provided. Its design is intended to be simple but flexible, in such a way that it can be robustly implemented and will not impinge on the general responsiveness of the Linux kernel. The following is a summary of the recent discussion on the linux-privs list. I am in the process of making a proposal that will be general enough to handle all of the following features: 99..11.. FFiirrsstt ssoommee kkeerrnneell iinnffrraassttrruuccttuurree:: +o basic (atomic) auditing facility +o two modes of access: blocking and non-blocking +o some sort of circular buffer arrangement with hooks for a module of some sort to store the audit data on some medium. +o such a module will accept rules that tell it what to audit and what to discard. +o perhaps we adopt the model of the firewalling rules. +o audit - session id for following login etc. process trees. +o minimal audit records include audit-id, uid and time plus raw numerical data (for off-line translation to readable text +o all audit records have the same prefix-header +o Fixed Header prefix contains a version number (audit readers will know how to deal with historical formats). 99..22.. WWhhaatt aauuddiitt rreeccoorrddss sshhoouulldd ccoonnttaaiinn?? +o Events to be audited are selected by event masks: union of system/user/file event masks. +o Proposed audit prefix header: +o audit header version (audit generation) __u8 +o length of audit record (bytes) __u16 +o machine id: __u16 +o kind of event (e.g. system call code): __u8 +o reason for logging (bitmask: audited syscall, audited file, audited user, audited group) __u32 +o timestamp (when audited) __u32 +o audit id (set by init or login etc., for following process evolution) __u32 +o user id, group id, program id, ... __u32 99..33.. NNeexxtt ssoommee PPoolliiccyy ((wwhheenn//wwhhaatt sshhoouulldd wwee aauuddiitt)):: +o Classes of event +o Group individual events into classes: file-access/system tweeking etc.. +o Audit primarily on class of event. +o Events that will always be audited (fixed events): +o all actions relating to the audit sybsystem itself +o all attempts to change the system date +o all actions relating to group and user attributes +o all definitions and deletions of MAC level names and level identifiers +o chages of init states +o all actions relating to lodable modules +o User level event classes: +o some method for defining user-level event groups: administrator can select etc. +o Events that may be audited +o file-access (open, connect, accept, close) +o changing of file attributes (chmod, chattr, umask, create) +o program execution (exec, fork, vfork, exit) +o "exits" - administrator hook to deny requests/grant requests/modify system etc., in the light of the event. 99..44.. UUsseerr lleevveell aauuddiittiinngg ((PPOOSSIIXX)):: +o POSIX only defines a method for writing audit records. +o Audit records are variable length +o each record contains header +o event type - indicates minimal information contained in record +o time +o result (success/failure) +o audit - id +o other stuff...(?) +o subject attributes +o information about the calling process. +o pid +o object structures +o contain information on objects associated with the audited event: +o files +o processes +o etc. +o event specific data: as directed by the event type. +o Functions: +o int aud_write(int fildes, aur_rec_t ar) +o special fildes = AUD_SYSTEM_LOG, to indicate that data is written to the system audit record. +o Policy: here we list audit event types (and the functions that they refer to) +o AUD_AET_AUD_SWITCH +o aud_switch() +o AUD_AET_AUD_WRITE +o aud_write() +o AUD_AET_CHDIR +o chdir() +o AUD_AET_CHMOD +o chmod() +o AUD_AET_CHOWN +o chown() +o AUD_AET_CREAT +o creat() +o AUD_AET_DUP +o dup(), dup2() +o AUD_AET_EXEC +o exec(), execl(), execlp(), execv(), execvp(), execle(), execve() +o AUD_AET_EXIT +o _exit() +o AUD_AET_FORK +o fork() +o AUD_AET_KILL +o kill() +o AUD_AET_LINK +o link() +o AUD_AET_MKDIR +o mkdir() +o AUD_AET_MKFIFO +o mkfifo() +o AUD_AET_OPEN +o open(), opendir() +o AUD_AET_PIPE +o pipe() +o AUD_AET_RENAME +o rename() +o AUD_AET_RMDIR +o rmdir() +o AUD_AET_SETGID +o setgid() +o AUD_AET_SETUID +o setuid() +o AUD_AET_UNLINK +o unlink() +o AUD_AET_UTIME +o utime() +o Define a minimus set of events that cannot be turned off: these preserve the integrety of the audit lof +o user and file bitmasks are provided to trace the behavior of the system with respect to specific files and users. These are OR'd together to determine if an event is to be logged. 99..55.. IInntteerrnnaall kkeerrnneell aauuddiittiinngg ffaacciilliittyy Here we discuss the manner in which the kernel records audited events. Any part of the kernel may audit an event. Only those user-level processes with their auditing capability set may audit an event with the kernel. Contingency is made for the possibility of the system log filling up. 99..66.. PPrreesseerrvviinngg tthhee aauuddiitt lloogg This section discusses the kernel hooks provided for making a hard- copy of the system log. 99..77.. AAuuddiittiinngg ppoolliiccyy This section describes the policies used to define what sorts of events are logged. It also introduces the preferred format for recording these audited events. 1100.. PPrroocceessss//ttaasskk ccrreeddeennttiiaallss In this section we cover the freedoms of a given process. These include items like resource limits. 1111.. AAcckknnoowwlleeddggeemmeennttss This document is edited by Andrew G. Morgan. Amendments and corrections should be emailed to . Contributors to the text of this document include: Hildo Biersma, Roland Buresund, Dave Dillow, Julie Haugh, David Holland, Alexander Kjeldaas, Andi Kleen, Darren Moffat, Ingo Molnar, Aleph One, Christos Ricudis, Ken Seefried, Theodore Ts'o, and Zefram (Andrew Main). 1122.. CCooppyyrriigghhtt//lliicceennssee ffoorr tthhiiss ddooccuummeenntt Copyright (c) 1997, Andrew G. Morgan . All rights reserved. Redistribution and use in source (sgml) and binary (derived) forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, and the entire permission notice in its entirety, including the disclaimer of warranties. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. Alternatively, this product may be distributed under the terms of the GNU General Public License (GPL), in which case the provisions of the GNU GPL are required instead of the above restrictions. (This clause is necessary due to a potential bad interaction between the GNU GPL and the restrictions contained in a BSD-style copyright.) THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. TTaabbllee ooff CCoonntteennttss 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. POSIX capabilities . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. CAP_CHOWN . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. CAP_DAC_OVERRIDE . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. CAP_DAC_READ_SEARCH . . . . . . . . . . . . . . . . . . . . 5 2.1.4. CAP_FOWNER . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. CAP_FSETID . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.6. CAP_KILL . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.7. CAP_LINK_DIR . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.8. CAP_SETFCAP . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.9. CAP_SETGID . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.10. CAP_SETUID . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.11. CAP_SIGMASK . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.12. CAP_MAC_DOWNGRADE . . . . . . . . . . . . . . . . . . . . 6 2.1.13. CAP_MAC_READ . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.14. CAP_MAC_RELABEL_SUBJ . . . . . . . . . . . . . . . . . . . 6 2.1.15. CAP_MAC_UPGRADE . . . . . . . . . . . . . . . . . . . . . 6 2.1.16. CAP_MAC_WRITE . . . . . . . . . . . . . . . . . . . . . . 7 2.1.17. CAP_INF_NOFLOAT_OBJ . . . . . . . . . . . . . . . . . . . 7 2.1.18. CAP_INF_NOFLOAT_SUBJ . . . . . . . . . . . . . . . . . . . 7 2.1.19. CAP_INF_RELABEL_OBJ . . . . . . . . . . . . . . . . . . . 7 2.1.20. CAP_INF_RELABEL_SUBJ . . . . . . . . . . . . . . . . . . . 7 2.1.21. CAP_AUDIT_CONTROL . . . . . . . . . . . . . . . . . . . . 7 2.1.22. CAP_AUDIT_WRITE . . . . . . . . . . . . . . . . . . . . . 7 2.2. Linux specific capabilities . . . . . . . . . . . . . . . . . 7 2.2.1. CAP_LINUX_IMMUTABLE . . . . . . . . . . . . . . . . . . . . 7 2.2.2. CAP_LINUX_KERNELD . . . . . . . . . . . . . . . . . . . . . 8 2.2.3. CAP_LINUX_INSMOD . . . . . . . . . . . . . . . . . . . . . 8 2.2.4. CAP_LINUX_RMMOD . . . . . . . . . . . . . . . . . . . . . . 8 2.2.5. CAP_LINUX_RAWIO . . . . . . . . . . . . . . . . . . . . . . 8 2.2.6. CAP_LINUX_ATTENTION . . . . . . . . . . . . . . . . . . . . 8 2.2.7. CAP_LINUX_RANDOM . . . . . . . . . . . . . . . . . . . . . 8 2.3. Other capabilities . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. CAP_NET_BIND_SERVICE . . . . . . . . . . . . . . . . . . . 8 2.3.2. CAP_NET_BROADCAST . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. CAP_NET_DEBUG . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.4. CAP_NET_FIREWALL . . . . . . . . . . . . . . . . . . . . . 8 2.3.5. CAP_NET_IFCONFIG . . . . . . . . . . . . . . . . . . . . . 8 2.3.6. CAP_NET_PACKET . . . . . . . . . . . . . . . . . . . . . . 8 2.3.7. CAP_NET_RAW . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.8. CAP_NET_ROUTE . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.9. CAP_NET_SETID . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.10. CAP_IPC_LOCK . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.11. CAP_IPC_OWNER . . . . . . . . . . . . . . . . . . . . . . 9 2.3.12. CAP_SYS_CHROOT . . . . . . . . . . . . . . . . . . . . . . 9 2.3.13. CAP_SYS_PTRACE . . . . . . . . . . . . . . . . . . . . . . 9 2.3.14. CAP_SYS_ACCOUNT . . . . . . . . . . . . . . . . . . . . . 9 2.3.15. CAP_SYS_ADMIN . . . . . . . . . . . . . . . . . . . . . . 9 2.3.16. CAP_SYS_BOOT . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.17. CAP_SYS_DEVICES . . . . . . . . . . . . . . . . . . . . . 9 2.3.18. CAP_SYS_NICE . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.19. CAP_SYS_RESOURCE . . . . . . . . . . . . . . . . . . . . . 9 2.3.20. CAP_SYS_TIME . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.21. CAP_SYS_TTY_CONFIG . . . . . . . . . . . . . . . . . . . . 10 2.3.22. CAP_SYS_QUOTA . . . . . . . . . . . . . . . . . . . . . . 10 3. Capability sets . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Sets of capabilities . . . . . . . . . . . . . . . . . . . . 11 3.1.1. The capability set type . . . . . . . . . . . . . . . . . . 11 3.1.2. Capability set macros . . . . . . . . . . . . . . . . . . . 11 3.1.2.1. _cap_raise(cap_value_t capability) . . . . . . . . . . . 11 3.1.2.2. _cap_lower(cap_value_t capability); . . . . . . . . . . 11 3.1.2.3. _cap_raised(cap_value_t capability); . . . . . . . . . . 11 3.2. Filesystem capabilitiy sets . . . . . . . . . . . . . . . . . 12 3.2.1. Inheritable (fI) . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Permitted (fP) . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Effective (fE) . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Process/task capabilities . . . . . . . . . . . . . . . . . . 12 3.3.1. Effective (pE) . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Inheritable (pI) . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Permitted (pP) . . . . . . . . . . . . . . . . . . . . . . 13 4. Access Control Lists (ACL) . . . . . . . . . . . . . . . . . . 15 5. Mandatory Access Control (MAC) . . . . . . . . . . . . . . . . 16 6. Information Labels (IL) . . . . . . . . . . . . . . . . . . . . 17 7. Sensitivity Labels (SL) . . . . . . . . . . . . . . . . . . . . 18 8. Integrity checking; system recovery . . . . . . . . . . . . . . 19 9. Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. First some kernel infrastructure: . . . . . . . . . . . . . . 20 9.2. What audit records should contain? . . . . . . . . . . . . . 20 9.3. Next some Policy (when/what should we audit): . . . . . . . . 21 9.4. User level auditing (POSIX): . . . . . . . . . . . . . . . . 21 9.5. Internal kernel auditing facility . . . . . . . . . . . . . . 24 9.6. Preserving the audit log . . . . . . . . . . . . . . . . . . 25 9.7. Auditing policy . . . . . . . . . . . . . . . . . . . . . . . 25 10. Process/task credentials . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 12. Copyright/license for this document . . . . . . . . . . . . . 28