€•5Œsphinx.addnodes”Œdocument”“”)”}”(Œ rawsource”Œ”Œchildren”]”(Œtranslations”Œ LanguagesNode”“”)”}”(hhh]”(hŒpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ refdomain”Œstd”Œreftype”Œdoc”Œ reftarget”Œ(/translations/zh_CN/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/zh_TW/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/it_IT/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/ja_JP/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/ko_KR/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/pt_BR/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ(/translations/sp_SP/security/credentials”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h hhŒ _document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒCredentials in Linux”h]”hŒCredentials in Linux”…””}”(hh¼h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhh·h²hh³ŒB/var/lib/git/docbuild/linux/Documentation/security/credentials.rst”h´KubhŒ paragraph”“”)”}”(hŒ'By: David Howells ”h]”(hŒBy: David Howells <”…””}”(hhÍh²hh³Nh´NubhŒ reference”“”)”}”(hŒdhowells@redhat.com”h]”hŒdhowells@redhat.com”…””}”(hh×h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:dhowells@redhat.com”uh1hÕhhÍubhŒ>”…””}”(hhÍh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khh·h²hubhŒtopic”“”)”}”(hhh]”hŒbullet_list”“”)”}”(hhh]”(hŒ list_item”“”)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒOverview”…””}”(hjh²hh³Nh´Nubah}”(h]”Œid1”ah ]”h"]”h$]”h&]”Œrefid”Œoverview”uh1hÕhjubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhhýubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒTypes of Credentials”…””}”(hj%h²hh³Nh´Nubah}”(h]”Œid2”ah ]”h"]”h$]”h&]”Œrefid”Œtypes-of-credentials”uh1hÕhj"ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒ File Markings”…””}”(hjGh²hh³Nh´Nubah}”(h]”Œid3”ah ]”h"]”h$]”h&]”Œrefid”Œ file-markings”uh1hÕhjDubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjAubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubhü)”}”(hhh]”(hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒTask Credentials”…””}”(hjih²hh³Nh´Nubah}”(h]”Œid4”ah ]”h"]”h$]”h&]”Œrefid”Œtask-credentials”uh1hÕhjfubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjcubh÷)”}”(hhh]”(hü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒImmutable Credentials”…””}”(hjˆh²hh³Nh´Nubah}”(h]”Œid5”ah ]”h"]”h$]”h&]”Œrefid”Œimmutable-credentials”uh1hÕhj…ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhj‚ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒAccessing Task Credentials”…””}”(hjªh²hh³Nh´Nubah}”(h]”Œid6”ah ]”h"]”h$]”h&]”Œrefid”Œaccessing-task-credentials”uh1hÕhj§ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhj¤ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒ&Accessing Another Taskâ€™s Credentials”…””}”(hjÌh²hh³Nh´Nubah}”(h]”Œid7”ah ]”h"]”h$]”h&]”Œrefid”Œ$accessing-another-task-s-credentials”uh1hÕhjÉubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjÆubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒAltering Credentials”…””}”(hjîh²hh³Nh´Nubah}”(h]”Œid8”ah ]”h"]”h$]”h&]”Œrefid”Œaltering-credentials”uh1hÕhjëubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjèubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒManaging Credentials”…””}”(hjh²hh³Nh´Nubah}”(h]”Œid9”ah ]”h"]”h$]”h&]”Œrefid”Œmanaging-credentials”uh1hÕhj ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhj ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubeh}”(h]”h ]”h"]”h$]”h&]”uh1höhjcubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒOpen File Credentials”…””}”(hj>h²hh³Nh´Nubah}”(h]”Œid10”ah ]”h"]”h$]”h&]”Œrefid”Œopen-file-credentials”uh1hÕhj;ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhj8ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubhü)”}”(hhh]”hÌ)”}”(hhh]”hÖ)”}”(hhh]”hŒ)Overriding the VFSâ€™s Use of Credentials”…””}”(hj`h²hh³Nh´Nubah}”(h]”Œid11”ah ]”h"]”h$]”h&]”Œrefid”Œ'overriding-the-vfs-s-use-of-credentials”uh1hÕhj]ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËhjZubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhhøubeh}”(h]”h ]”h"]”h$]”h&]”uh1höhhóh²hh³Nh´Nubah}”(h]”Œcontents”ah ]”(Œcontents”Œlocal”eh"]”Œcontents”ah$]”h&]”uh1hñh³hÊh´Khh·h²hubh¶)”}”(hhh]”(h»)”}”(hŒOverview”h]”hŒOverview”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefid”juh1hºhjŒh²hh³hÊh´K ubhÌ)”}”(hŒcThere are several parts to the security check performed by Linux when one object acts upon another:”h]”hŒcThere are several parts to the security check performed by Linux when one object acts upon another:”…””}”(hjžh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhjŒh²hubhŒblock_quote”“”)”}”(hXS1. Objects. Objects are things in the system that may be acted upon directly by userspace programs. Linux has a variety of actionable objects, including: - Tasks - Files/inodes - Sockets - Message queues - Shared memory segments - Semaphores - Keys As a part of the description of all these objects there is a set of credentials. What's in the set depends on the type of object. 2. Object ownership. Amongst the credentials of most objects, there will be a subset that indicates the ownership of that object. This is used for resource accounting and limitation (disk quotas and task rlimits for example). In a standard UNIX filesystem, for instance, this will be defined by the UID marked on the inode. 3. The objective context. Also amongst the credentials of those objects, there will be a subset that indicates the 'objective context' of that object. This may or may not be the same set as in (2) - in standard UNIX files, for instance, this is the defined by the UID and the GID marked on the inode. The objective context is used as part of the security calculation that is carried out when an object is acted upon. 4. Subjects. A subject is an object that is acting upon another object. Most of the objects in the system are inactive: they don't act on other objects within the system. Processes/tasks are the obvious exception: they do stuff; they access and manipulate things. Objects other than tasks may under some circumstances also be subjects. For instance an open file may send SIGIO to a task using the UID and EUID given to it by a task that called ``fcntl(F_SETOWN)`` upon it. In this case, the file struct will have a subjective context too. 5. The subjective context. A subject has an additional interpretation of its credentials. A subset of its credentials forms the 'subjective context'. The subjective context is used as part of the security calculation that is carried out when a subject acts. A Linux task, for example, has the FSUID, FSGID and the supplementary group list for when it is acting upon a file - which are quite separate from the real UID and GID that normally form the objective context of the task. 6. Actions. Linux has a number of actions available that a subject may perform upon an object. The set of actions available depends on the nature of the subject and the object. Actions include reading, writing, creating and deleting files; forking or signalling and tracing tasks. 7. Rules, access control lists and security calculations. When a subject acts upon an object, a security calculation is made. This involves taking the subjective context, the objective context and the action, and searching one or more sets of rules to see whether the subject is granted or denied permission to act in the desired manner on the object, given those contexts. There are two main sources of rules: a. Discretionary access control (DAC): Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL. A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use. A Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects. b. Mandatory access control (MAC): The system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this. In the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied. ”h]”hŒenumerated_list”“”)”}”(hhh]”(hü)”}”(hXObjects. Objects are things in the system that may be acted upon directly by userspace programs. Linux has a variety of actionable objects, including: - Tasks - Files/inodes - Sockets - Message queues - Shared memory segments - Semaphores - Keys As a part of the description of all these objects there is a set of credentials. What's in the set depends on the type of object. ”h]”(hÌ)”}”(hŒObjects.”h]”hŒObjects.”…””}”(hj»h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj·ubj)”}”(hXˆObjects are things in the system that may be acted upon directly by userspace programs. Linux has a variety of actionable objects, including: - Tasks - Files/inodes - Sockets - Message queues - Shared memory segments - Semaphores - Keys As a part of the description of all these objects there is a set of credentials. What's in the set depends on the type of object. ”h]”(hÌ)”}”(hŒŽObjects are things in the system that may be acted upon directly by userspace programs. Linux has a variety of actionable objects, including:”h]”hŒŽObjects are things in the system that may be acted upon directly by userspace programs. Linux has a variety of actionable objects, including:”…””}”(hjÍh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhjÉubj)”}”(hŒ_- Tasks - Files/inodes - Sockets - Message queues - Shared memory segments - Semaphores - Keys ”h]”h÷)”}”(hhh]”(hü)”}”(hŒTasks”h]”hÌ)”}”(hjäh]”hŒTasks”…””}”(hjæh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khjâubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒFiles/inodes”h]”hÌ)”}”(hjûh]”hŒFiles/inodes”…””}”(hjýh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khjùubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒSockets”h]”hÌ)”}”(hjh]”hŒSockets”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khjubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒMessage queues”h]”hÌ)”}”(hj)h]”hŒMessage queues”…””}”(hj+h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj'ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒShared memory segments”h]”hÌ)”}”(hj@h]”hŒShared memory segments”…””}”(hjBh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj>ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒ Semaphores”h]”hÌ)”}”(hjWh]”hŒ Semaphores”…””}”(hjYh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhjUubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubhü)”}”(hŒKeys ”h]”hÌ)”}”(hŒKeys”h]”hŒKeys”…””}”(hjph²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khjlubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjßubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1höh³hÊh´KhjÛubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KhjÉubhÌ)”}”(hŒ‚As a part of the description of all these objects there is a set of credentials. What's in the set depends on the type of object.”h]”hŒ„As a part of the description of all these objects there is a set of credentials. Whatâ€™s in the set depends on the type of object.”…””}”(hj’h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhjÉubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Khj·ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hXIObject ownership. Amongst the credentials of most objects, there will be a subset that indicates the ownership of that object. This is used for resource accounting and limitation (disk quotas and task rlimits for example). In a standard UNIX filesystem, for instance, this will be defined by the UID marked on the inode. ”h]”(hÌ)”}”(hŒObject ownership.”h]”hŒObject ownership.”…””}”(hj°h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj¬ubj)”}”(hX1Amongst the credentials of most objects, there will be a subset that indicates the ownership of that object. This is used for resource accounting and limitation (disk quotas and task rlimits for example). In a standard UNIX filesystem, for instance, this will be defined by the UID marked on the inode. ”h]”(hÌ)”}”(hŒÍAmongst the credentials of most objects, there will be a subset that indicates the ownership of that object. This is used for resource accounting and limitation (disk quotas and task rlimits for example).”h]”hŒÍAmongst the credentials of most objects, there will be a subset that indicates the ownership of that object. This is used for resource accounting and limitation (disk quotas and task rlimits for example).”…””}”(hjÂh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K!hj¾ubhÌ)”}”(hŒaIn a standard UNIX filesystem, for instance, this will be defined by the UID marked on the inode.”h]”hŒaIn a standard UNIX filesystem, for instance, this will be defined by the UID marked on the inode.”…””}”(hjÐh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K%hj¾ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K!hj¬ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hX§The objective context. Also amongst the credentials of those objects, there will be a subset that indicates the 'objective context' of that object. This may or may not be the same set as in (2) - in standard UNIX files, for instance, this is the defined by the UID and the GID marked on the inode. The objective context is used as part of the security calculation that is carried out when an object is acted upon. ”h]”(hÌ)”}”(hŒThe objective context.”h]”hŒThe objective context.”…””}”(hjîh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K(hjêubj)”}”(hX‰Also amongst the credentials of those objects, there will be a subset that indicates the 'objective context' of that object. This may or may not be the same set as in (2) - in standard UNIX files, for instance, this is the defined by the UID and the GID marked on the inode. The objective context is used as part of the security calculation that is carried out when an object is acted upon. ”h]”(hÌ)”}”(hXAlso amongst the credentials of those objects, there will be a subset that indicates the 'objective context' of that object. This may or may not be the same set as in (2) - in standard UNIX files, for instance, this is the defined by the UID and the GID marked on the inode.”h]”hXAlso amongst the credentials of those objects, there will be a subset that indicates the â€˜objective contextâ€™ of that object. This may or may not be the same set as in (2) - in standard UNIX files, for instance, this is the defined by the UID and the GID marked on the inode.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K*hjüubhÌ)”}”(hŒsThe objective context is used as part of the security calculation that is carried out when an object is acted upon.”h]”hŒsThe objective context is used as part of the security calculation that is carried out when an object is acted upon.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K/hjüubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K*hjêubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hX%Subjects. A subject is an object that is acting upon another object. Most of the objects in the system are inactive: they don't act on other objects within the system. Processes/tasks are the obvious exception: they do stuff; they access and manipulate things. Objects other than tasks may under some circumstances also be subjects. For instance an open file may send SIGIO to a task using the UID and EUID given to it by a task that called ``fcntl(F_SETOWN)`` upon it. In this case, the file struct will have a subjective context too. ”h]”(hÌ)”}”(hŒ Subjects.”h]”hŒ Subjects.”…””}”(hj,h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K2hj(ubj)”}”(hXA subject is an object that is acting upon another object. Most of the objects in the system are inactive: they don't act on other objects within the system. Processes/tasks are the obvious exception: they do stuff; they access and manipulate things. Objects other than tasks may under some circumstances also be subjects. For instance an open file may send SIGIO to a task using the UID and EUID given to it by a task that called ``fcntl(F_SETOWN)`` upon it. In this case, the file struct will have a subjective context too. ”h]”(hÌ)”}”(hŒ:A subject is an object that is acting upon another object.”h]”hŒ:A subject is an object that is acting upon another object.”…””}”(hj>h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K4hj:ubhÌ)”}”(hŒÀMost of the objects in the system are inactive: they don't act on other objects within the system. Processes/tasks are the obvious exception: they do stuff; they access and manipulate things.”h]”hŒÂMost of the objects in the system are inactive: they donâ€™t act on other objects within the system. Processes/tasks are the obvious exception: they do stuff; they access and manipulate things.”…””}”(hjLh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K6hj:ubhÌ)”}”(hXObjects other than tasks may under some circumstances also be subjects. For instance an open file may send SIGIO to a task using the UID and EUID given to it by a task that called ``fcntl(F_SETOWN)`` upon it. In this case, the file struct will have a subjective context too.”h]”(hŒ´Objects other than tasks may under some circumstances also be subjects. For instance an open file may send SIGIO to a task using the UID and EUID given to it by a task that called ”…””}”(hjZh²hh³Nh´NubhŒliteral”“”)”}”(hŒ``fcntl(F_SETOWN)``”h]”hŒfcntl(F_SETOWN)”…””}”(hjdh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjZubhŒL upon it. In this case, the file struct will have a subjective context too.”…””}”(hjZh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K:hj:ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K4hj(ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hXéThe subjective context. A subject has an additional interpretation of its credentials. A subset of its credentials forms the 'subjective context'. The subjective context is used as part of the security calculation that is carried out when a subject acts. A Linux task, for example, has the FSUID, FSGID and the supplementary group list for when it is acting upon a file - which are quite separate from the real UID and GID that normally form the objective context of the task. ”h]”(hÌ)”}”(hŒThe subjective context.”h]”hŒThe subjective context.”…””}”(hjŒh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K?hjˆubj)”}”(hXÈA subject has an additional interpretation of its credentials. A subset of its credentials forms the 'subjective context'. The subjective context is used as part of the security calculation that is carried out when a subject acts. A Linux task, for example, has the FSUID, FSGID and the supplementary group list for when it is acting upon a file - which are quite separate from the real UID and GID that normally form the objective context of the task. ”h]”(hÌ)”}”(hŒèA subject has an additional interpretation of its credentials. A subset of its credentials forms the 'subjective context'. The subjective context is used as part of the security calculation that is carried out when a subject acts.”h]”hŒìA subject has an additional interpretation of its credentials. A subset of its credentials forms the â€˜subjective contextâ€™. The subjective context is used as part of the security calculation that is carried out when a subject acts.”…””}”(hjžh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KAhjšubhÌ)”}”(hŒÝA Linux task, for example, has the FSUID, FSGID and the supplementary group list for when it is acting upon a file - which are quite separate from the real UID and GID that normally form the objective context of the task.”h]”hŒÝA Linux task, for example, has the FSUID, FSGID and the supplementary group list for when it is acting upon a file - which are quite separate from the real UID and GID that normally form the objective context of the task.”…””}”(hj¬h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KFhjšubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KAhjˆubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hXActions. Linux has a number of actions available that a subject may perform upon an object. The set of actions available depends on the nature of the subject and the object. Actions include reading, writing, creating and deleting files; forking or signalling and tracing tasks. ”h]”(hÌ)”}”(hŒActions.”h]”hŒActions.”…””}”(hjÊh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KKhjÆubj)”}”(hXLinux has a number of actions available that a subject may perform upon an object. The set of actions available depends on the nature of the subject and the object. Actions include reading, writing, creating and deleting files; forking or signalling and tracing tasks. ”h]”(hÌ)”}”(hŒ¥Linux has a number of actions available that a subject may perform upon an object. The set of actions available depends on the nature of the subject and the object.”h]”hŒ¥Linux has a number of actions available that a subject may perform upon an object. The set of actions available depends on the nature of the subject and the object.”…””}”(hjÜh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KMhjØubhÌ)”}”(hŒgActions include reading, writing, creating and deleting files; forking or signalling and tracing tasks.”h]”hŒgActions include reading, writing, creating and deleting files; forking or signalling and tracing tasks.”…””}”(hjêh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KQhjØubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KMhjÆubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubhü)”}”(hX°Rules, access control lists and security calculations. When a subject acts upon an object, a security calculation is made. This involves taking the subjective context, the objective context and the action, and searching one or more sets of rules to see whether the subject is granted or denied permission to act in the desired manner on the object, given those contexts. There are two main sources of rules: a. Discretionary access control (DAC): Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL. A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use. A Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects. b. Mandatory access control (MAC): The system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this. In the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied. ”h]”(hÌ)”}”(hŒ6Rules, access control lists and security calculations.”h]”hŒ6Rules, access control lists and security calculations.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KThjubj)”}”(hX^When a subject acts upon an object, a security calculation is made. This involves taking the subjective context, the objective context and the action, and searching one or more sets of rules to see whether the subject is granted or denied permission to act in the desired manner on the object, given those contexts. There are two main sources of rules: a. Discretionary access control (DAC): Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL. A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use. A Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects. b. Mandatory access control (MAC): The system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this. In the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied. ”h]”(hÌ)”}”(hX<When a subject acts upon an object, a security calculation is made. This involves taking the subjective context, the objective context and the action, and searching one or more sets of rules to see whether the subject is granted or denied permission to act in the desired manner on the object, given those contexts.”h]”hX<When a subject acts upon an object, a security calculation is made. This involves taking the subjective context, the objective context and the action, and searching one or more sets of rules to see whether the subject is granted or denied permission to act in the desired manner on the object, given those contexts.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KVhjubhÌ)”}”(hŒ$There are two main sources of rules:”h]”hŒ$There are two main sources of rules:”…””}”(hj(h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K\hjubj³)”}”(hhh]”(hü)”}”(hXæDiscretionary access control (DAC): Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL. A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use. A Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects. ”h]”(hÌ)”}”(hŒ#Discretionary access control (DAC):”h]”hŒ#Discretionary access control (DAC):”…””}”(hj=h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K^hj9ubj)”}”(hX¶Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL. A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use. A Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects. ”h]”(hÌ)”}”(hŒ£Sometimes the object will include sets of rules as part of its description. This is an 'Access Control List' or 'ACL'. A Linux file may supply more than one ACL.”h]”hŒ«Sometimes the object will include sets of rules as part of its description. This is an â€˜Access Control Listâ€™ or â€˜ACLâ€™. A Linux file may supply more than one ACL.”…””}”(hjOh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K`hjKubhÌ)”}”(hX”A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject ('user', 'group' and 'other'), each of which may be granted certain privileges ('read', 'write' and 'execute' - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use.”h]”hX¬A traditional UNIX file, for example, includes a permissions mask that is an abbreviated ACL with three fixed classes of subject (â€˜userâ€™, â€˜groupâ€™ and â€˜otherâ€™), each of which may be granted certain privileges (â€˜readâ€™, â€˜writeâ€™ and â€˜executeâ€™ - whatever those map to for the object in question). UNIX file permissions do not allow the arbitrary specification of subjects, however, and so are of limited use.”…””}”(hj]h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KdhjKubhÌ)”}”(hŒzA Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects.”h]”hŒzA Linux file might also sport a POSIX ACL. This is a list of rules that grants various permissions to arbitrary subjects.”…””}”(hjkh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KkhjKubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K`hj9ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj6ubhü)”}”(hX×Mandatory access control (MAC): The system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this. In the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied. ”h]”(hÌ)”}”(hŒMandatory access control (MAC):”h]”hŒMandatory access control (MAC):”…””}”(hj‰h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Knhj…ubj)”}”(hX¯The system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this. In the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied. ”h]”(hÌ)”}”(hŒªThe system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this.”h]”hŒªThe system as a whole may have one or more sets of rules that get applied to all subjects and objects, regardless of their source. SELinux and Smack are examples of this.”…””}”(hj›h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kphj—ubhÌ)”}”(hXIn the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied.”h]”hXIn the case of SELinux and Smack, each object is given a label as part of its credentials. When an action is requested, they take the subject label, the object label and the action and look for a rule that says that this action is either granted or denied.”…””}”(hj©h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kthj—ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Kphj…ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj6ubeh}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œ loweralpha”Œprefix”hŒsuffix”Œ.”uh1j²hjubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KVhjubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ubeh}”(h]”h ]”h"]”h$]”h&]”jÉŒarabic”jËhjÌjÍuh1j²hj®ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KhjŒh²hubeh}”(h]”jah ]”h"]”Œoverview”ah$]”h&]”uh1hµhh·h²hh³hÊh´K ubh¶)”}”(hhh]”(h»)”}”(hŒTypes of Credentials”h]”hŒTypes of Credentials”…””}”(hjñh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jj.uh1hºhjîh²hh³hÊh´K{ubhÌ)”}”(hŒ=The Linux kernel supports the following types of credentials:”h]”hŒ=The Linux kernel supports the following types of credentials:”…””}”(hjÿh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K}hjîh²hubj)”}”(hXß 1. Traditional UNIX credentials. - Real User ID - Real Group ID The UID and GID are carried by most, if not all, Linux objects, even if in some cases it has to be invented (FAT or CIFS files for example, which are derived from Windows). These (mostly) define the objective context of that object, with tasks being slightly different in some cases. - Effective, Saved and FS User ID - Effective, Saved and FS Group ID - Supplementary groups These are additional credentials used by tasks only. Usually, an EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID will be used as the objective. For tasks, it should be noted that this is not always true. 2. Capabilities. - Set of permitted capabilities - Set of inheritable capabilities - Set of effective capabilities - Capability bounding set These are only carried by tasks. They indicate superior capabilities granted piecemeal to a task that an ordinary task wouldn't otherwise have. These are manipulated implicitly by changes to the traditional UNIX credentials, but can also be manipulated directly by the ``capset()`` system call. The permitted capabilities are those caps that the process might grant itself to its effective or permitted sets through ``capset()``. This inheritable set might also be so constrained. The effective capabilities are the ones that a task is actually allowed to make use of itself. The inheritable capabilities are the ones that may get passed across ``execve()``. The bounding set limits the capabilities that may be inherited across ``execve()``, especially when a binary is executed that will execute as UID 0. 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. 4. Keys and keyrings. These are only carried by tasks. They carry and cache security tokens that don't fit into the other standard UNIX credentials. They are for making such things as network filesystem keys available to the file accesses performed by processes, without the necessity of ordinary programs having to know about security details involved. Keyrings are a special type of key. They carry sets of other keys and can be searched for the desired key. Each process may subscribe to a number of keyrings: - Per-thread keyring - Per-process keyring - Per-session keyring When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find. For more information on using keys, see ``Documentation/security/keys/*``. 5. LSM The Linux Security Module allows extra controls to be placed over the operations that a task may do. Currently Linux supports several LSM options. Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label. 6. AF_KEY This is a socket-based approach to credential management for networking stacks [RFC 2367]. It isn't discussed by this document as it doesn't interact directly with task and file credentials; rather it keeps system level credentials. ”h]”j³)”}”(hhh]”(hü)”}”(hX¾Traditional UNIX credentials. - Real User ID - Real Group ID The UID and GID are carried by most, if not all, Linux objects, even if in some cases it has to be invented (FAT or CIFS files for example, which are derived from Windows). These (mostly) define the objective context of that object, with tasks being slightly different in some cases. - Effective, Saved and FS User ID - Effective, Saved and FS Group ID - Supplementary groups These are additional credentials used by tasks only. Usually, an EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID will be used as the objective. For tasks, it should be noted that this is not always true. ”h]”(hÌ)”}”(hŒTraditional UNIX credentials.”h]”hŒTraditional UNIX credentials.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khjubj)”}”(hX’ - Real User ID - Real Group ID The UID and GID are carried by most, if not all, Linux objects, even if in some cases it has to be invented (FAT or CIFS files for example, which are derived from Windows). These (mostly) define the objective context of that object, with tasks being slightly different in some cases. - Effective, Saved and FS User ID - Effective, Saved and FS Group ID - Supplementary groups These are additional credentials used by tasks only. Usually, an EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID will be used as the objective. For tasks, it should be noted that this is not always true. ”h]”(j)”}”(hŒ- Real User ID - Real Group ID ”h]”h÷)”}”(hhh]”(hü)”}”(hŒReal User ID”h]”hÌ)”}”(hj3h]”hŒReal User ID”…””}”(hj5h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj1ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj.ubhü)”}”(hŒReal Group ID ”h]”hÌ)”}”(hŒ Real Group ID”h]”hŒ Real Group ID”…””}”(hjLh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K‚hjHubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj.ubeh}”(h]”h ]”h"]”h$]”h&]”jŠj‹uh1höh³hÊh´Khj*ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Khj&ubhÌ)”}”(hXThe UID and GID are carried by most, if not all, Linux objects, even if in some cases it has to be invented (FAT or CIFS files for example, which are derived from Windows). These (mostly) define the objective context of that object, with tasks being slightly different in some cases.”h]”hXThe UID and GID are carried by most, if not all, Linux objects, even if in some cases it has to be invented (FAT or CIFS files for example, which are derived from Windows). These (mostly) define the objective context of that object, with tasks being slightly different in some cases.”…””}”(hjlh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K„hj&ubj)”}”(hŒ\- Effective, Saved and FS User ID - Effective, Saved and FS Group ID - Supplementary groups ”h]”h÷)”}”(hhh]”(hü)”}”(hŒEffective, Saved and FS User ID”h]”hÌ)”}”(hjƒh]”hŒEffective, Saved and FS User ID”…””}”(hj…h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K‰hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj~ubhü)”}”(hŒ Effective, Saved and FS Group ID”h]”hÌ)”}”(hjšh]”hŒ Effective, Saved and FS Group ID”…””}”(hjœh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KŠhj˜ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj~ubhü)”}”(hŒSupplementary groups ”h]”hÌ)”}”(hŒSupplementary groups”h]”hŒSupplementary groups”…””}”(hj³h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K‹hj¯ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj~ubeh}”(h]”h ]”h"]”h$]”h&]”jŠj‹uh1höh³hÊh´K‰hjzubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K‰hj&ubhÌ)”}”(hŒçThese are additional credentials used by tasks only. Usually, an EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID will be used as the objective. For tasks, it should be noted that this is not always true.”h]”hŒçThese are additional credentials used by tasks only. Usually, an EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID will be used as the objective. For tasks, it should be noted that this is not always true.”…””}”(hjÓh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj&ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Khjubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hXÙCapabilities. - Set of permitted capabilities - Set of inheritable capabilities - Set of effective capabilities - Capability bounding set These are only carried by tasks. They indicate superior capabilities granted piecemeal to a task that an ordinary task wouldn't otherwise have. These are manipulated implicitly by changes to the traditional UNIX credentials, but can also be manipulated directly by the ``capset()`` system call. The permitted capabilities are those caps that the process might grant itself to its effective or permitted sets through ``capset()``. This inheritable set might also be so constrained. The effective capabilities are the ones that a task is actually allowed to make use of itself. The inheritable capabilities are the ones that may get passed across ``execve()``. The bounding set limits the capabilities that may be inherited across ``execve()``, especially when a binary is executed that will execute as UID 0. ”h]”(hÌ)”}”(hŒ Capabilities.”h]”hŒ Capabilities.”…””}”(hjñh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K’hjíubj)”}”(hX· - Set of permitted capabilities - Set of inheritable capabilities - Set of effective capabilities - Capability bounding set These are only carried by tasks. They indicate superior capabilities granted piecemeal to a task that an ordinary task wouldn't otherwise have. These are manipulated implicitly by changes to the traditional UNIX credentials, but can also be manipulated directly by the ``capset()`` system call. The permitted capabilities are those caps that the process might grant itself to its effective or permitted sets through ``capset()``. This inheritable set might also be so constrained. The effective capabilities are the ones that a task is actually allowed to make use of itself. The inheritable capabilities are the ones that may get passed across ``execve()``. The bounding set limits the capabilities that may be inherited across ``execve()``, especially when a binary is executed that will execute as UID 0. ”h]”(j)”}”(hŒ|- Set of permitted capabilities - Set of inheritable capabilities - Set of effective capabilities - Capability bounding set ”h]”h÷)”}”(hhh]”(hü)”}”(hŒSet of permitted capabilities”h]”hÌ)”}”(hjh]”hŒSet of permitted capabilities”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K”hj ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hŒSet of inheritable capabilities”h]”hÌ)”}”(hj#h]”hŒSet of inheritable capabilities”…””}”(hj%h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K•hj!ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hŒSet of effective capabilities”h]”hÌ)”}”(hj:h]”hŒSet of effective capabilities”…””}”(hj<h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K–hj8ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hŒCapability bounding set ”h]”hÌ)”}”(hŒCapability bounding set”h]”hŒCapability bounding set”…””}”(hjSh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K—hjOubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubeh}”(h]”h ]”h"]”h$]”h&]”jŠj‹uh1höh³hÊh´K”hjubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K”hjÿubhÌ)”}”(hX'These are only carried by tasks. They indicate superior capabilities granted piecemeal to a task that an ordinary task wouldn't otherwise have. These are manipulated implicitly by changes to the traditional UNIX credentials, but can also be manipulated directly by the ``capset()`` system call.”h]”(hXThese are only carried by tasks. They indicate superior capabilities granted piecemeal to a task that an ordinary task wouldnâ€™t otherwise have. These are manipulated implicitly by changes to the traditional UNIX credentials, but can also be manipulated directly by the ”…””}”(hjsh²hh³Nh´Nubjc)”}”(hŒ``capset()``”h]”hŒcapset()”…””}”(hj{h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjsubhŒ system call.”…””}”(hjsh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K™hjÿubhÌ)”}”(hŒºThe permitted capabilities are those caps that the process might grant itself to its effective or permitted sets through ``capset()``. This inheritable set might also be so constrained.”h]”(hŒyThe permitted capabilities are those caps that the process might grant itself to its effective or permitted sets through ”…””}”(hj“h²hh³Nh´Nubjc)”}”(hŒ``capset()``”h]”hŒcapset()”…””}”(hj›h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj“ubhŒ5. This inheritable set might also be so constrained.”…””}”(hj“h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KŸhjÿubhÌ)”}”(hŒ^The effective capabilities are the ones that a task is actually allowed to make use of itself.”h]”hŒ^The effective capabilities are the ones that a task is actually allowed to make use of itself.”…””}”(hj³h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K£hjÿubhÌ)”}”(hŒRThe inheritable capabilities are the ones that may get passed across ``execve()``.”h]”(hŒEThe inheritable capabilities are the ones that may get passed across ”…””}”(hjÁh²hh³Nh´Nubjc)”}”(hŒ``execve()``”h]”hŒexecve()”…””}”(hjÉh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjÁubhŒ.”…””}”(hjÁh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¦hjÿubhÌ)”}”(hŒ”The bounding set limits the capabilities that may be inherited across ``execve()``, especially when a binary is executed that will execute as UID 0.”h]”(hŒFThe bounding set limits the capabilities that may be inherited across ”…””}”(hjáh²hh³Nh´Nubjc)”}”(hŒ``execve()``”h]”hŒexecve()”…””}”(hjéh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjáubhŒB, especially when a binary is executed that will execute as UID 0.”…””}”(hjáh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K©hjÿubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K”hjíubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hXSecure 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. ”h]”(hÌ)”}”(hŒ%Secure management flags (securebits).”h]”hŒ%Secure management flags (securebits).”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj ubj)”}”(hŒØ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. ”h]”hÌ)”}”(hŒ×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.”h]”hŒÙ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.”…””}”(hj#h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¯hjubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K¯hj ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hX2Keys and keyrings. These are only carried by tasks. They carry and cache security tokens that don't fit into the other standard UNIX credentials. They are for making such things as network filesystem keys available to the file accesses performed by processes, without the necessity of ordinary programs having to know about security details involved. Keyrings are a special type of key. They carry sets of other keys and can be searched for the desired key. Each process may subscribe to a number of keyrings: - Per-thread keyring - Per-process keyring - Per-session keyring When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find. For more information on using keys, see ``Documentation/security/keys/*``. ”h]”(hÌ)”}”(hŒKeys and keyrings.”h]”hŒKeys and keyrings.”…””}”(hjAh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K´hj=ubj)”}”(hXThese are only carried by tasks. They carry and cache security tokens that don't fit into the other standard UNIX credentials. They are for making such things as network filesystem keys available to the file accesses performed by processes, without the necessity of ordinary programs having to know about security details involved. Keyrings are a special type of key. They carry sets of other keys and can be searched for the desired key. Each process may subscribe to a number of keyrings: - Per-thread keyring - Per-process keyring - Per-session keyring When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find. For more information on using keys, see ``Documentation/security/keys/*``. ”h]”(hÌ)”}”(hXMThese are only carried by tasks. They carry and cache security tokens that don't fit into the other standard UNIX credentials. They are for making such things as network filesystem keys available to the file accesses performed by processes, without the necessity of ordinary programs having to know about security details involved.”h]”hXOThese are only carried by tasks. They carry and cache security tokens that donâ€™t fit into the other standard UNIX credentials. They are for making such things as network filesystem keys available to the file accesses performed by processes, without the necessity of ordinary programs having to know about security details involved.”…””}”(hjSh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¶hjOubhÌ)”}”(hŒ Keyrings are a special type of key. They carry sets of other keys and can be searched for the desired key. Each process may subscribe to a number of keyrings:”h]”hŒ Keyrings are a special type of key. They carry sets of other keys and can be searched for the desired key. Each process may subscribe to a number of keyrings:”…””}”(hjah²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¼hjOubj)”}”(hŒA- Per-thread keyring - Per-process keyring - Per-session keyring ”h]”h÷)”}”(hhh]”(hü)”}”(hŒPer-thread keyring”h]”hÌ)”}”(hjxh]”hŒPer-thread keyring”…””}”(hjzh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÀhjvubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjsubhü)”}”(hŒPer-process keyring”h]”hÌ)”}”(hjh]”hŒPer-process keyring”…””}”(hj‘h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÁhjubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjsubhü)”}”(hŒPer-session keyring ”h]”hÌ)”}”(hŒPer-session keyring”h]”hŒPer-session keyring”…””}”(hj¨h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÂhj¤ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjsubeh}”(h]”h ]”h"]”h$]”h&]”jŠj‹uh1höh³hÊh´KÀhjoubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KÀhjOubhÌ)”}”(hŒ‡When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find.”h]”hŒ‡When a process accesses a key, if not already present, it will normally be cached on one of these keyrings for future accesses to find.”…””}”(hjÈh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÄhjOubhÌ)”}”(hŒJFor more information on using keys, see ``Documentation/security/keys/*``.”h]”(hŒ(For more information on using keys, see ”…””}”(hjÖh²hh³Nh´Nubjc)”}”(hŒ!``Documentation/security/keys/*``”h]”hŒDocumentation/security/keys/*”…””}”(hjÞh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjÖubhŒ.”…””}”(hjÖh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÇhjOubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´K¶hj=ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hXQLSM The Linux Security Module allows extra controls to be placed over the operations that a task may do. Currently Linux supports several LSM options. Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label. ”h]”(hÌ)”}”(hŒLSM”h]”hŒLSM”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÉhj ubj)”}”(hXFThe Linux Security Module allows extra controls to be placed over the operations that a task may do. Currently Linux supports several LSM options. Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label. ”h]”(hÌ)”}”(hŒ“The Linux Security Module allows extra controls to be placed over the operations that a task may do. Currently Linux supports several LSM options.”h]”hŒ“The Linux Security Module allows extra controls to be placed over the operations that a task may do. Currently Linux supports several LSM options.”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KËhj ubhÌ)”}”(hŒ°Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label.”h]”hŒ°Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label.”…””}”(hj& h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÏhj ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KËhj ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubhü)”}”(hŒ÷AF_KEY This is a socket-based approach to credential management for networking stacks [RFC 2367]. It isn't discussed by this document as it doesn't interact directly with task and file credentials; rather it keeps system level credentials. ”h]”(hÌ)”}”(hŒAF_KEY”h]”hŒAF_KEY”…””}”(hjD h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÓhj@ ubj)”}”(hŒëThis is a socket-based approach to credential management for networking stacks [RFC 2367]. It isn't discussed by this document as it doesn't interact directly with task and file credentials; rather it keeps system level credentials. ”h]”hÌ)”}”(hŒéThis is a socket-based approach to credential management for networking stacks [RFC 2367]. It isn't discussed by this document as it doesn't interact directly with task and file credentials; rather it keeps system level credentials.”h]”hŒíThis is a socket-based approach to credential management for networking stacks [RFC 2367]. It isnâ€™t discussed by this document as it doesnâ€™t interact directly with task and file credentials; rather it keeps system level credentials.”…””}”(hjV h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÕhjR ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´KÕhj@ ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjubeh}”(h]”h ]”h"]”h$]”h&]”jÉjàjËhjÌjÍuh1j²hj ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Khjîh²hubhÌ)”}”(hXËWhen a file is opened, part of the opening task's subjective context is recorded in the file struct created. This allows operations using that file struct to use those credentials instead of the subjective context of the task that issued the operation. An example of this would be a file opened on a network filesystem where the credentials of the opened file should be presented to the server, regardless of who is actually doing a read or a write upon it.”h]”hXÍWhen a file is opened, part of the opening taskâ€™s subjective context is recorded in the file struct created. This allows operations using that file struct to use those credentials instead of the subjective context of the task that issued the operation. An example of this would be a file opened on a network filesystem where the credentials of the opened file should be presented to the server, regardless of who is actually doing a read or a write upon it.”…””}”(hj| h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÛhjîh²hubeh}”(h]”j4ah ]”h"]”Œtypes of credentials”ah$]”h&]”uh1hµhh·h²hh³hÊh´K{ubh¶)”}”(hhh]”(h»)”}”(hŒ File Markings”h]”hŒ File Markings”…””}”(hj” h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jjPuh1hºhj‘ h²hh³hÊh´KäubhÌ)”}”(hŒËFiles on disk or obtained over the network may have annotations that form the objective security context of that file. Depending on the type of filesystem, this may include one or more of the following:”h]”hŒËFiles on disk or obtained over the network may have annotations that form the objective security context of that file. Depending on the type of filesystem, this may include one or more of the following:”…””}”(hj¢ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kæhj‘ h²hubj)”}”(hŒ¾* UNIX UID, GID, mode; * Windows user ID; * Access control list; * LSM security label; * UNIX exec privilege escalation bits (SUID/SGID); * File capabilities exec privilege escalation bits. ”h]”h÷)”}”(hhh]”(hü)”}”(hŒUNIX UID, GID, mode;”h]”hÌ)”}”(hj¹ h]”hŒUNIX UID, GID, mode;”…””}”(hj» h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kêhj· ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubhü)”}”(hŒWindows user ID;”h]”hÌ)”}”(hjÐ h]”hŒWindows user ID;”…””}”(hjÒ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KëhjÎ ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubhü)”}”(hŒAccess control list;”h]”hÌ)”}”(hjç h]”hŒAccess control list;”…””}”(hjé h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kìhjå ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubhü)”}”(hŒLSM security label;”h]”hÌ)”}”(hjþ h]”hŒLSM security label;”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kíhjü ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubhü)”}”(hŒ0UNIX exec privilege escalation bits (SUID/SGID);”h]”hÌ)”}”(hj h]”hŒ0UNIX exec privilege escalation bits (SUID/SGID);”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kîhj ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubhü)”}”(hŒ2File capabilities exec privilege escalation bits. ”h]”hÌ)”}”(hŒ1File capabilities exec privilege escalation bits.”h]”hŒ1File capabilities exec privilege escalation bits.”…””}”(hj. h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kïhj* ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj´ ubeh}”(h]”h ]”h"]”h$]”h&]”jŠŒ*”uh1höh³hÊh´Kêhj° ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Kêhj‘ h²hubhÌ)”}”(hX&These are compared to the task's subjective security context, and certain operations allowed or disallowed as a result. In the case of execve(), the privilege escalation bits come into play, and may allow the resulting process extra privileges, based on the annotations on the executable file.”h]”hX(These are compared to the taskâ€™s subjective security context, and certain operations allowed or disallowed as a result. In the case of execve(), the privilege escalation bits come into play, and may allow the resulting process extra privileges, based on the annotations on the executable file.”…””}”(hjO h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kñhj‘ h²hubeh}”(h]”jVah ]”h"]”Œ file markings”ah$]”h&]”uh1hµhh·h²hh³hÊh´Käubh¶)”}”(hhh]”(h»)”}”(hŒTask Credentials”h]”hŒTask Credentials”…””}”(hjg h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jjruh1hºhjd h²hh³hÊh´KøubhÌ)”}”(hŒåIn Linux, all of a task's credentials are held in (uid, gid) or through (groups, keys, LSM security) a refcounted structure of type 'struct cred'. Each task points to its credentials by a pointer called 'cred' in its task_struct.”h]”hŒïIn Linux, all of a taskâ€™s credentials are held in (uid, gid) or through (groups, keys, LSM security) a refcounted structure of type â€˜struct credâ€™. Each task points to its credentials by a pointer called â€˜credâ€™ in its task_struct.”…””}”(hju h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kúhjd h²hubhÌ)”}”(hŒsOnce a set of credentials has been prepared and committed, it may not be changed, barring the following exceptions:”h]”hŒsOnce a set of credentials has been prepared and committed, it may not be changed, barring the following exceptions:”…””}”(hjƒ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kÿhjd h²hubj)”}”(hX$1. its reference count may be changed; 2. the reference count on the group_info struct it points to may be changed; 3. the reference count on the security data it points to may be changed; 4. the reference count on any keyrings it points to may be changed; 5. any keyrings it points to may be revoked, expired or have their security attributes changed; and 6. the contents of any keyrings to which it points may be changed (the whole point of keyrings being a shared set of credentials, modifiable by anyone with appropriate access). ”h]”j³)”}”(hhh]”(hü)”}”(hŒ$its reference count may be changed; ”h]”hÌ)”}”(hŒ#its reference count may be changed;”h]”hŒ#its reference count may be changed;”…””}”(hjœ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj˜ ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubhü)”}”(hŒJthe reference count on the group_info struct it points to may be changed; ”h]”hÌ)”}”(hŒIthe reference count on the group_info struct it points to may be changed;”h]”hŒIthe reference count on the group_info struct it points to may be changed;”…””}”(hj´ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj° ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubhü)”}”(hŒFthe reference count on the security data it points to may be changed; ”h]”hÌ)”}”(hŒEthe reference count on the security data it points to may be changed;”h]”hŒEthe reference count on the security data it points to may be changed;”…””}”(hjÌ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MhjÈ ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubhü)”}”(hŒAthe reference count on any keyrings it points to may be changed; ”h]”hÌ)”}”(hŒ@the reference count on any keyrings it points to may be changed;”h]”hŒ@the reference count on any keyrings it points to may be changed;”…””}”(hjä h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjà ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubhü)”}”(hŒaany keyrings it points to may be revoked, expired or have their security attributes changed; and ”h]”hÌ)”}”(hŒ`any keyrings it points to may be revoked, expired or have their security attributes changed; and”h]”hŒ`any keyrings it points to may be revoked, expired or have their security attributes changed; and”…””•ãž}”(hjü h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M hjø ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubhü)”}”(hŒ®the contents of any keyrings to which it points may be changed (the whole point of keyrings being a shared set of credentials, modifiable by anyone with appropriate access). ”h]”hÌ)”}”(hŒthe contents of any keyrings to which it points may be changed (the whole point of keyrings being a shared set of credentials, modifiable by anyone with appropriate access).”h]”hŒthe contents of any keyrings to which it points may be changed (the whole point of keyrings being a shared set of credentials, modifiable by anyone with appropriate access).”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj• ubeh}”(h]”h ]”h"]”h$]”h&]”jÉjàjËhjÌjÍuh1j²hj‘ ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Mhjd h²hubhÌ)”}”(hXTo alter anything in the cred struct, the copy-and-replace principle must be adhered to. First take a copy, then alter the copy and then use RCU to change the task pointer to make it point to the new copy. There are wrappers to aid with this (see below).”h]”hXTo alter anything in the cred struct, the copy-and-replace principle must be adhered to. First take a copy, then alter the copy and then use RCU to change the task pointer to make it point to the new copy. There are wrappers to aid with this (see below).”…””}”(hj4h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjd h²hubhÌ)”}”(hXµA task may only alter its _own_ credentials; it is no longer permitted for a task to alter another's credentials. This means the ``capset()`` system call is no longer permitted to take any PID other than the one of the current process. Also ``keyctl_instantiate()`` and ``keyctl_negate()`` functions no longer permit attachment to process-specific keyrings in the requesting process as the instantiating process may need to create them.”h]”(hŒ„A task may only alter its _own_ credentials; it is no longer permitted for a task to alter anotherâ€™s credentials. This means the ”…””}”(hjBh²hh³Nh´Nubjc)”}”(hŒ``capset()``”h]”hŒcapset()”…””}”(hjJh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjBubhŒd system call is no longer permitted to take any PID other than the one of the current process. Also ”…””}”(hjBh²hh³Nh´Nubjc)”}”(hŒ``keyctl_instantiate()``”h]”hŒkeyctl_instantiate()”…””}”(hj\h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjBubhŒ and ”…””}”(hjBh²hh³Nh´Nubjc)”}”(hŒ``keyctl_negate()``”h]”hŒkeyctl_negate()”…””}”(hjnh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjBubhŒ“ functions no longer permit attachment to process-specific keyrings in the requesting process as the instantiating process may need to create them.”…””}”(hjBh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjd h²hubh¶)”}”(hhh]”(h»)”}”(hŒImmutable Credentials”h]”hŒImmutable Credentials”…””}”(hj‰h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jj‘uh1hºhj†h²hh³hÊh´MubhÌ)”}”(hŒ”Once a set of credentials has been made public (by calling ``commit_creds()`` for example), it must be considered immutable, barring two exceptions:”h]”(hŒ;Once a set of credentials has been made public (by calling ”…””}”(hj—h²hh³Nh´Nubjc)”}”(hŒ``commit_creds()``”h]”hŒcommit_creds()”…””}”(hjŸh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj—ubhŒG for example), it must be considered immutable, barring two exceptions:”…””}”(hj—h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M!hj†h²hubj)”}”(hŒ¶1. The reference count may be altered. 2. While the keyring subscriptions of a set of credentials may not be changed, the keyrings subscribed to may have their contents altered. ”h]”j³)”}”(hhh]”(hü)”}”(hŒ$The reference count may be altered. ”h]”hÌ)”}”(hŒ#The reference count may be altered.”h]”hŒ#The reference count may be altered.”…””}”(hjÂh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M$hj¾ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj»ubhü)”}”(hŒˆWhile the keyring subscriptions of a set of credentials may not be changed, the keyrings subscribed to may have their contents altered. ”h]”hÌ)”}”(hŒ‡While the keyring subscriptions of a set of credentials may not be changed, the keyrings subscribed to may have their contents altered.”h]”hŒ‡While the keyring subscriptions of a set of credentials may not be changed, the keyrings subscribed to may have their contents altered.”…””}”(hjÚh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M&hjÖubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhj»ubeh}”(h]”h ]”h"]”h$]”h&]”jÉjàjËhjÌjÍuh1j²hj·ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´M$hj†h²hubhÌ)”}”(hXxTo catch accidental credential alteration at compile time, struct task_struct has _const_ pointers to its credential sets, as does struct file. Furthermore, certain functions such as ``get_cred()`` and ``put_cred()`` operate on const pointers, thus rendering casts unnecessary, but require to temporarily ditch the const qualification to be able to alter the reference count.”h]”(hŒ¸To catch accidental credential alteration at compile time, struct task_struct has _const_ pointers to its credential sets, as does struct file. Furthermore, certain functions such as ”…””}”(hjúh²hh³Nh´Nubjc)”}”(hŒ``get_cred()``”h]”hŒ get_cred()”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjúubhŒ and ”…””}”(hjúh²hh³Nh´Nubjc)”}”(hŒ``put_cred()``”h]”hŒ put_cred()”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjúubhŒŸ operate on const pointers, thus rendering casts unnecessary, but require to temporarily ditch the const qualification to be able to alter the reference count.”…””}”(hjúh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M)hj†h²hubeh}”(h]”j—ah ]”h"]”Œimmutable credentials”ah$]”h&]”uh1hµhjd h²hh³hÊh´Mubh¶)”}”(hhh]”(h»)”}”(hŒAccessing Task Credentials”h]”hŒAccessing Task Credentials”…””}”(hj6h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jj³uh1hºhj3h²hh³hÊh´M1ubhÌ)”}”(hŒ×A task being able to alter only its own credentials permits the current process to read or replace its own credentials without the need for any form of locking -- which simplifies things greatly. It can just call::”h]”hŒÖA task being able to alter only its own credentials permits the current process to read or replace its own credentials without the need for any form of locking -- which simplifies things greatly. It can just call:”…””}”(hjDh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M3hj3h²hubhŒ literal_block”“”)”}”(hŒ!const struct cred *current_cred()”h]”hŒ!const struct cred *current_cred()”…””}”hjTsbah}”(h]”h ]”h"]”h$]”h&]”Œ xml:space”Œpreserve”uh1jRh³hÊh´M7hj3h²hubhÌ)”}”(hŒ\to get a pointer to its credentials structure, and it doesn't have to release it afterwards.”h]”hŒ^to get a pointer to its credentials structure, and it doesnâ€™t have to release it afterwards.”…””}”(hjdh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M9hj3h²hubhÌ)”}”(hŒ„There are convenience wrappers for retrieving specific aspects of a task's credentials (the value is simply returned in each case)::”h]”hŒ…There are convenience wrappers for retrieving specific aspects of a taskâ€™s credentials (the value is simply returned in each case):”…””}”(hjrh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Muid = tcred->uid; f->gid = tcred->gid; f->groups = get_group_info(tcred->groups); rcu_read_unlock(); ... }”h]”hX2void foo(struct task_struct *t, struct foo_data *f) { const struct cred *tcred; ... rcu_read_lock(); tcred = __task_cred(t); f->uid = tcred->uid; f->gid = tcred->gid; f->groups = get_group_info(tcred->groups); rcu_read_unlock(); ... }”…””}”hj¶ sbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´MrhjI h²hubhÌ)”}”(hŒ±Should it be necessary to hold another task's credentials for a long period of time, and possibly to sleep while doing so, then the caller should get a reference on them using::”h]”hŒ²Should it be necessary to hold another taskâ€™s credentials for a long period of time, and possibly to sleep while doing so, then the caller should get a reference on them using:”…””}”(hjÄ h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MhjI h²hubjS)”}”(hŒ;const struct cred *get_task_cred(struct task_struct *task);”h]”hŒ;const struct cred *get_task_cred(struct task_struct *task);”…””}”hjÒ sbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´MƒhjI h²hubhÌ)”}”(hŒ…This does all the RCU magic inside of it. The caller must call put_cred() on the credentials so obtained when they're finished with.”h]”hŒ‡This does all the RCU magic inside of it. The caller must call put_cred() on the credentials so obtained when theyâ€™re finished with.”…””}”(hjà h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M…hjI h²hubhŒnote”“”)”}”(hŒxThe result of ``__task_cred()`` should not be passed directly to ``get_cred()`` as this may race with ``commit_cred()``.”h]”hÌ)”}”(hŒxThe result of ``__task_cred()`` should not be passed directly to ``get_cred()`` as this may race with ``commit_cred()``.”h]”(hŒThe result of ”…””}”(hjô h²hh³Nh´Nubjc)”}”(hŒ``__task_cred()``”h]”hŒ __task_cred()”…””}”(hjü h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjô ubhŒ" should not be passed directly to ”…””}”(hjô h²hh³Nh´Nubjc)”}”(hŒ``get_cred()``”h]”hŒ get_cred()”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjô ubhŒ as this may race with ”…””}”(hjô h²hh³Nh´Nubjc)”}”(hŒ``commit_cred()``”h]”hŒ commit_cred()”…””}”(hj h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjô ubhŒ.”…””}”(hjô h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M‰hjð ubah}”(h]”h ]”h"]”h$]”h&]”uh1jî hjI h²hh³hÊh´NubhÌ)”}”(hŒtThere is a convenience function to access bits of another task's credentials, hiding the RCU magic from the caller::”h]”hŒuThere is a convenience function to access bits of another taskâ€™s credentials, hiding the RCU magic from the caller:”…””}”(hj>h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MŒhjI h²hubjS)”}”(hŒ/uid_t task_uid(task) Task's real UID”h]”hŒ/uid_t task_uid(task) Task's real UID”…””}”hjLsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´MhjI h²hubhÌ)”}”(hŒEIf the caller is holding the RCU read lock at the time anyway, then::”h]”hŒDIf the caller is holding the RCU read lock at the time anyway, then:”…””}”(hjZh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M‘hjI h²hubjS)”}”(hŒ__task_cred(task)->uid”h]”hŒ__task_cred(task)->uid”…””}”hjhsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´M“hjI h²hubhÌ)”}”(hXfshould be used instead. Similarly, if multiple aspects of a task's credentials need to be accessed, RCU read lock should be used, ``__task_cred()`` called, the result stored in a temporary pointer and then the credential aspects called from that before dropping the lock. This prevents the potentially expensive RCU magic from being invoked multiple times.”h]”(hŒ…should be used instead. Similarly, if multiple aspects of a taskâ€™s credentials need to be accessed, RCU read lock should be used, ”…””}”(hjvh²hh³Nh´Nubjc)”}”(hŒ``__task_cred()``”h]”hŒ __task_cred()”…””}”(hj~h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjvubhŒÒ called, the result stored in a temporary pointer and then the credential aspects called from that before dropping the lock. This prevents the potentially expensive RCU magic from being invoked multiple times.”…””}”(hjvh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M•hjI h²hubhÌ)”}”(hŒjShould some other single aspect of another task's credentials need to be accessed, then this can be used::”h]”hŒkShould some other single aspect of another taskâ€™s credentials need to be accessed, then this can be used:”…””}”(hj–h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M›hjI h²hubjS)”}”(hŒtask_cred_xxx(task, member)”h]”hŒtask_cred_xxx(task, member)”…””}”hj¤sbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´MžhjI h²hubhÌ)”}”(hŒJwhere 'member' is a non-pointer member of the cred struct. For instance::”h]”hŒMwhere â€˜memberâ€™ is a non-pointer member of the cred struct. For instance:”…””}”(hj²h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M hjI h²hubjS)”}”(hŒ uid_t task_cred_xxx(task, suid);”h]”hŒ uid_t task_cred_xxx(task, suid);”…””}”hjÀsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´M¢hjI h²hubhÌ)”}”(hŒÈwill retrieve 'struct cred::suid' from the task, doing the appropriate RCU magic. This may not be used for pointer members as what they point to may disappear the moment the RCU read lock is dropped.”h]”hŒÌwill retrieve â€˜struct cred::suidâ€™ from the task, doing the appropriate RCU magic. This may not be used for pointer members as what they point to may disappear the moment the RCU read lock is dropped.”…””}”(hjÎh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¤hjI h²hubeh}”(h]”jÛah ]”h"]”Œ$accessing another task's credentials”ah$]”h&]”uh1hµhjd h²hh³hÊh´Mfubh¶)”}”(hhh]”(h»)”}”(hŒAltering Credentials”h]”hŒAltering Credentials”…””}”(hjæh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jj÷uh1hºhjãh²hh³hÊh´MªubhÌ)”}”(hŒ¾As previously mentioned, a task may only alter its own credentials, and may not alter those of another task. This means that it doesn't need to use any locking to alter its own credentials.”h]”hŒÀAs previously mentioned, a task may only alter its own credentials, and may not alter those of another task. This means that it doesnâ€™t need to use any locking to alter its own credentials.”…””}”(hjôh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¬hjãh²hubhÌ)”}”(hŒqTo alter the current process's credentials, a function should first prepare a new set of credentials by calling::”h]”hŒrTo alter the current processâ€™s credentials, a function should first prepare a new set of credentials by calling:”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M°hjãh²hubjS)”}”(hŒ!struct cred *prepare_creds(void);”h]”hŒ!struct cred *prepare_creds(void);”…””}”hjsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´M³hjãh²hubhÌ)”}”(hŒáthis locks current->cred_replace_mutex and then allocates and constructs a duplicate of the current process's credentials, returning with the mutex still held if successful. It returns NULL if not successful (out of memory).”h]”hŒãthis locks current->cred_replace_mutex and then allocates and constructs a duplicate of the current processâ€™s credentials, returning with the mutex still held if successful. It returns NULL if not successful (out of memory).”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mµhjãh²hubhÌ)”}”(hŒïThe mutex prevents ``ptrace()`` from altering the ptrace state of a process while security checks on credentials construction and changing is taking place as the ptrace state may alter the outcome, particularly in the case of ``execve()``.”h]”(hŒThe mutex prevents ”…””}”(hj,h²hh³Nh´Nubjc)”}”(hŒ``ptrace()``”h]”hŒptrace()”…””}”(hj4h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj,ubhŒÃ from altering the ptrace state of a process while security checks on credentials construction and changing is taking place as the ptrace state may alter the outcome, particularly in the case of ”…””}”(hj,h²hh³Nh´Nubjc)”}”(hŒ``execve()``”h]”hŒexecve()”…””}”(hjFh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj,ubhŒ.”…””}”(hj,h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¹hjãh²hubhÌ)”}”(hŒùThe new credentials set should be altered appropriately, and any security checks and hooks done. Both the current and the proposed sets of credentials are available for this purpose as current_cred() will return the current set still at this point.”h]”hŒùThe new credentials set should be altered appropriately, and any security checks and hooks done. Both the current and the proposed sets of credentials are available for this purpose as current_cred() will return the current set still at this point.”…””}”(hj^h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¾hjãh²hubhÌ)”}”(hX£When replacing the group list, the new list must be sorted before it is added to the credential, as a binary search is used to test for membership. In practice, this means groups_sort() should be called before set_groups() or set_current_groups(). groups_sort() must not be called on a ``struct group_list`` which is shared as it may permute elements as part of the sorting process even if the array is already sorted.”h]”(hXWhen replacing the group list, the new list must be sorted before it is added to the credential, as a binary search is used to test for membership. In practice, this means groups_sort() should be called before set_groups() or set_current_groups(). groups_sort() must not be called on a ”…””}”(hjlh²hh³Nh´Nubjc)”}”(hŒ``struct group_list``”h]”hŒstruct group_list”…””}”(hjth²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjlubhŒo which is shared as it may permute elements as part of the sorting process even if the array is already sorted.”…””}”(hjlh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÃhjãh²hubhÌ)”}”(hŒ\When the credential set is ready, it should be committed to the current process by calling::”h]”hŒ[When the credential set is ready, it should be committed to the current process by calling:”…””}”(hjŒh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MËhjãh²hubjS)”}”(hŒ#int commit_creds(struct cred *new);”h]”hŒ#int commit_creds(struct cred *new);”…””}”hjšsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´MÎhjãh²hubhÌ)”}”(hXcThis will alter various aspects of the credentials and the process, giving the LSM a chance to do likewise, then it will use ``rcu_assign_pointer()`` to actually commit the new credentials to ``current->cred``, it will release ``current->cred_replace_mutex`` to allow ``ptrace()`` to take place, and it will notify the scheduler and others of the changes.”h]”(hŒ}This will alter various aspects of the credentials and the process, giving the LSM a chance to do likewise, then it will use ”…””}”(hj¨h²hh³Nh´Nubjc)”}”(hŒ``rcu_assign_pointer()``”h]”hŒrcu_assign_pointer()”…””}”(hj°h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj¨ubhŒ+ to actually commit the new credentials to ”…””}”(hj¨h²hh³Nh´Nubjc)”}”(hŒ``current->cred``”h]”hŒ current->cred”…””}”(hjÂh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj¨ubhŒ, it will release ”…””}”(hj¨h²hh³Nh´Nubjc)”}”(hŒ``current->cred_replace_mutex``”h]”hŒcurrent->cred_replace_mutex”…””}”(hjÔh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj¨ubhŒ to allow ”…””}”(hj¨h²hh³Nh´Nubjc)”}”(hŒ``ptrace()``”h]”hŒptrace()”…””}”(hjæh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj¨ubhŒK to take place, and it will notify the scheduler and others of the changes.”…””}”(hj¨h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÐhjãh²hubhÌ)”}”(hŒ{This function is guaranteed to return 0, so that it can be tail-called at the end of such functions as ``sys_setresuid()``.”h]”(hŒgThis function is guaranteed to return 0, so that it can be tail-called at the end of such functions as ”…””}”(hjþh²hh³Nh´Nubjc)”}”(hŒ``sys_setresuid()``”h]”hŒsys_setresuid()”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjþubhŒ.”…””}”(hjþh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÖhjãh²hubhÌ)”}”(hŒžNote that this function consumes the caller's reference to the new credentials. The caller should _not_ call ``put_cred()`` on the new credentials afterwards.”h]”(hŒoNote that this function consumes the callerâ€™s reference to the new credentials. The caller should _not_ call ”…””}”(hjh²hh³Nh´Nubjc)”}”(hŒ``put_cred()``”h]”hŒ put_cred()”…””}”(hj&h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjubhŒ# on the new credentials afterwards.”…””}”(hjh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÙhjãh²hubhÌ)”}”(hŒ|Furthermore, once this function has been called on a new set of credentials, those credentials may _not_ be changed further.”h]”hŒ|Furthermore, once this function has been called on a new set of credentials, those credentials may _not_ be changed further.”…””}”(hj>h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÜhjãh²hubhÌ)”}”(hŒ”Should the security checks fail or some other error occur after ``prepare_creds()`` has been called, then the following function should be invoked::”h]”(hŒ@Should the security checks fail or some other error occur after ”…””}”(hjLh²hh³Nh´Nubjc)”}”(hŒ``prepare_creds()``”h]”hŒprepare_creds()”…””}”(hjTh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjLubhŒ@ has been called, then the following function should be invoked:”…””}”(hjLh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Màhjãh²hubjS)”}”(hŒ#void abort_creds(struct cred *new);”h]”hŒ#void abort_creds(struct cred *new);”…””}”hjlsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´Mähjãh²hubhÌ)”}”(hŒ}This releases the lock on ``current->cred_replace_mutex`` that ``prepare_creds()`` got and then releases the new credentials.”h]”(hŒThis releases the lock on ”…””}”(hjzh²hh³Nh´Nubjc)”}”(hŒ``current->cred_replace_mutex``”h]”hŒcurrent->cred_replace_mutex”…””}”(hj‚h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjzubhŒ that ”…””}”(hjzh²hh³Nh´Nubjc)”}”(hŒ``prepare_creds()``”h]”hŒprepare_creds()”…””}”(hj”h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjzubhŒ+ got and then releases the new credentials.”…””}”(hjzh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mæhjãh²hubhÌ)”}”(hŒJA typical credentials alteration function would look something like this::”h]”hŒIA typical credentials alteration function would look something like this:”…””}”(hj¬h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mêhjãh²hubjS)”}”(hX`int alter_suid(uid_t suid) { struct cred *new; int ret; new = prepare_creds(); if (!new) return -ENOMEM; new->suid = suid; ret = security_alter_suid(new); if (ret < 0) { abort_creds(new); return ret; } return commit_creds(new); }”h]”hX`int alter_suid(uid_t suid) { struct cred *new; int ret; new = prepare_creds(); if (!new) return -ENOMEM; new->suid = suid; ret = security_alter_suid(new); if (ret < 0) { abort_creds(new); return ret; } return commit_creds(new); }”…””}”hjºsbah}”(h]”h ]”h"]”h$]”h&]”jbjcuh1jRh³hÊh´Mìhjãh²hubeh}”(h]”jýah ]”h"]”Œaltering credentials”ah$]”h&]”uh1hµhjd h²hh³hÊh´Mªubh¶)”}”(hhh]”(h»)”}”(hŒManaging Credentials”h]”hŒManaging Credentials”…””}”(hjÒh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jjuh1hºhjÏh²hh³hÊh´MubhÌ)”}”(hŒ4There are some functions to help manage credentials:”h]”hŒ4There are some functions to help manage credentials:”…””}”(hjàh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MhjÏh²hubj)”}”(hXŒ- ``void put_cred(const struct cred *cred);`` This releases a reference to the given set of credentials. If the reference count reaches zero, the credentials will be scheduled for destruction by the RCU system. - ``const struct cred *get_cred(const struct cred *cred);`` This gets a reference on a live set of credentials, returning a pointer to that set of credentials. ”h]”h÷)”}”(hhh]”(hü)”}”(hŒÙ``void put_cred(const struct cred *cred);`` This releases a reference to the given set of credentials. If the reference count reaches zero, the credentials will be scheduled for destruction by the RCU system. ”h]”(hÌ)”}”(hŒ+``void put_cred(const struct cred *cred);``”h]”jc)”}”(hjûh]”hŒ'void put_cred(const struct cred *cred);”…””}”(hjýh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjùubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjõubj)”}”(hŒ¦This releases a reference to the given set of credentials. If the reference count reaches zero, the credentials will be scheduled for destruction by the RCU system. ”h]”hÌ)”}”(hŒ¥This releases a reference to the given set of credentials. If the reference count reaches zero, the credentials will be scheduled for destruction by the RCU system.”h]”hŒ¥This releases a reference to the given set of credentials. If the reference count reaches zero, the credentials will be scheduled for destruction by the RCU system.”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´Mhjõubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjòubhü)”}”(hŒ¤``const struct cred *get_cred(const struct cred *cred);`` This gets a reference on a live set of credentials, returning a pointer to that set of credentials. ”h]”(hÌ)”}”(hŒ9``const struct cred *get_cred(const struct cred *cred);``”h]”jc)”}”(hj4h]”hŒ5const struct cred *get_cred(const struct cred *cred);”…””}”(hj6h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj2ubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj.ubj)”}”(hŒeThis gets a reference on a live set of credentials, returning a pointer to that set of credentials. ”h]”hÌ)”}”(hŒcThis gets a reference on a live set of credentials, returning a pointer to that set of credentials.”h]”hŒcThis gets a reference on a live set of credentials, returning a pointer to that set of credentials.”…””}”(hjMh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M hjIubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´M hj.ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hûhjòubeh}”(h]”h ]”h"]”h$]”h&]”jŠj‹uh1höh³hÊh´Mhjîubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´MhjÏh²hubeh}”(h]”jah ]”h"]”Œmanaging credentials”ah$]”h&]”uh1hµhjd h²hh³hÊh´Mubeh}”(h]”jxah ]”h"]”Œtask credentials”ah$]”h&]”uh1hµhh·h²hh³hÊh´Køubh¶)”}”(hhh]”(h»)”}”(hŒOpen File Credentials”h]”hŒOpen File Credentials”…””}”(hj„h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jjGuh1hºhjh²hh³hÊh´MubhÌ)”}”(hX4When a new file is opened, a reference is obtained on the opening task's credentials and this is attached to the file struct as ``f_cred`` in place of ``f_uid`` and ``f_gid``. Code that used to access ``file->f_uid`` and ``file->f_gid`` should now access ``file->f_cred->fsuid`` and ``file->f_cred->fsgid``.”h]”(hŒ‚When a new file is opened, a reference is obtained on the opening taskâ€™s credentials and this is attached to the file struct as ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ ``f_cred``”h]”hŒf_cred”…””}”(hjšh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ in place of ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ ``f_uid``”h]”hŒf_uid”…””}”(hj¬h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ and ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ ``f_gid``”h]”hŒf_gid”…””}”(hj¾h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ. Code that used to access ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ``file->f_uid``”h]”hŒfile->f_uid”…””}”(hjÐh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ and ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ``file->f_gid``”h]”hŒfile->f_gid”…””}”(hjâh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ should now access ”…””}”(hj’h²hh³Nh´Nubjc)”}”(hŒ``file->f_cred->fsuid``”h]”hŒfile->f_cred->fsuid”…””}”(hjôh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ and ”…””}”hj’sbjc)”}”(hŒ``file->f_cred->fsgid``”h]”hŒfile->f_cred->fsgid”…””}”(hjh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj’ubhŒ.”…””}”(hj’h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjh²hubhÌ)”}”(hXIt is safe to access ``f_cred`` without the use of RCU or locking because the pointer will not change over the lifetime of the file struct, and nor will the contents of the cred struct pointed to, barring the exceptions listed above (see the Task Credentials section).”h]”(hŒIt is safe to access ”…””}”(hjh²hh³Nh´Nubjc)”}”(hŒ ``f_cred``”h]”hŒf_cred”…””}”(hj&h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjubhŒí without the use of RCU or locking because the pointer will not change over the lifetime of the file struct, and nor will the contents of the cred struct pointed to, barring the exceptions listed above (see the Task Credentials section).”…””}”(hjh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjh²hubhÌ)”}”(hŒýTo avoid "confused deputy" privilege escalation attacks, access control checks during subsequent operations on an opened file should use these credentials instead of "current"'s credentials, as the file may have been passed to a more privileged process.”h]”hXTo avoid â€œconfused deputyâ€ privilege escalation attacks, access control checks during subsequent operations on an opened file should use these credentials instead of â€œcurrentâ€œâ€˜s credentials, as the file may have been passed to a more privileged process.”…””}”(hj>h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjh²hubeh}”(h]”jMah ]”h"]”Œopen file credentials”ah$]”h&]”uh1hµhh·h²hh³hÊh´Mubh¶)”}”(hhh]”(h»)”}”(hŒ'Overriding the VFS's Use of Credentials”h]”hŒ)Overriding the VFSâ€™s Use of Credentials”…””}”(hjVh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”jjiuh1hºhjSh²hh³hÊh´M%ubhÌ)”}”(hŒÞUnder some circumstances it is desirable to override the credentials used by the VFS, and that can be done by calling into such as ``vfs_mkdir()`` with a different set of credentials. This is done in the following places:”h]”(hŒƒUnder some circumstances it is desirable to override the credentials used by the VFS, and that can be done by calling into such as ”…””}”(hjdh²hh³Nh´Nubjc)”}”(hŒ``vfs_mkdir()``”h]”hŒvfs_mkdir()”…””}”(hjlh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjdubhŒL with a different set of credentials. This is done in the following places:”…””}”(hjdh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M'hjSh²hubj)”}”(hŒ=* ``sys_faccessat()``. * ``vfs_coredump()``. * nfs4recover.c.”h]”h÷)”}”(hhh]”(hü)”}”(hŒ``sys_faccessat()``.”h]”hÌ)”}”(hjh]”(jc)”}”(hŒ``sys_faccessat()``”h]”hŒsys_faccessat()”…””}”(hj’h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhjubhŒ.”…””}”(hjh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M+hj‹ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjˆubhü)”}”(hŒ``vfs_coredump()``.”h]”hÌ)”}”(hj²h]”(jc)”}”(hŒ``vfs_coredump()``”h]”hŒvfs_coredump()”…””}”(hj·h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jbhj´ubhŒ.”…””}”(hj´h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M,hj°ubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjˆubhü)”}”(hŒnfs4recover.c.”h]”hÌ)”}”(hj×h]”hŒnfs4recover.c.”…””}”(hjÙh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M-hjÕubah}”(h]”h ]”h"]”h$]”h&]”uh1hûhjˆubeh}”(h]”h ]”h"]”h$]”h&]”jŠjH uh1höh³hÊh´M+hj„ubah}”(h]”h ]”h"]”h$]”h&]”uh1j¬h³hÊh´M+hjSh²hubeh}”(h]”joah ]”h"]”Œ'overriding the vfs's use of credentials”ah$]”h&]”uh1hµhh·h²hh³hÊh´M%ubeh}”(h]”Œcredentials-in-linux”ah ]”h"]”Œcredentials in linux”ah$]”h&]”uh1hµhhh²hh³hÊh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÊuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hºNŒ generator”NŒ datestamp”NŒsource_link”NŒ source_url”NŒ toc_backlinks”Œentry”Œfootnote_backlinks”KŒ sectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒ strip_classes”NŒreport_level”KŒ halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ traceback”ˆŒinput_encoding”Œ utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j*Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œ language_code”Œen”Œrecord_dependencies”NŒconfig”NŒ id_prefix”hŒauto_id_prefix”Œid”Œ dump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÊŒ_destination”NŒ _config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œ docinfo_xform”KŒsectsubtitle_xform”‰Œ image_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(jjj‰j„jëjjŽ j4ja jVj~jxj0j—jF j¹jàjÛjÌjýjwjjPjMjüjouŒ nametypes”}”(j‰j‰‰jë‰jŽ ‰ja ‰j~‰j0‰jF ‰jà‰jÌ‰jw‰jP‰jü‰uh}”(jh·j„hójjŒj4jîjVj‘ jxjd j—j†j¹j3jÛjI jýjãjjÏjMjjojSjjj.j%jPjGjrjij‘jˆj³jªjÕjÌj÷jîjjjGj>jij`uŒ footnote_refs”}”Œ citation_refs”}”Œ autofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ footnotes”]”Œ citations”]”Œautofootnote_start”KŒsymbol_footnote_start”KŒ id_counter”Œcollections”ŒCounter”“”}”j8Ks…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ decoration”Nh²hub.