Difference between revisions of "NB LSM"

From SELinux Wiki
Jump to: navigation, search
(Process Transition Walk-thorough)
(The SELinux Module)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= Linux Security Module and SELinux =
 
= Linux Security Module and SELinux =
This section gives a high level overview of the LSM and SELinux internal structure and workings. A more detailed view can be found in the "[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]" that was used extensively to develop this section (with the SELinux kernel source code). The major areas covered are:
+
This section gives a high level overview of the LSM and SELinux internal kernel structure and workings as enabled in kernel 3.14. A more detailed view can be found in the "[http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml Implementing SELinux as a Linux Security Module]" that was used extensively to develop this section (and also using the SELinux kernel source code). The major areas covered are:
 
+
# How the LSM and SELinux modules work together.
* How the LSM and SELinux modules work together.
+
# The major SELinux internal services.
* The major SELinux internal services.
+
# The <tt>fork</tt> and <tt>exec</tt> system calls are followed through as an example to tie in with the transition process covered in the [[NB_Domain_and_Object_Transitions#Domain Transition | Domain Transition]] section.
* The fork system call and exec are followed through as an example to tie in with the transition process covered in the [[NB_Objects#Domain_Transition | Domain and Object Transitions]] section.
+
# The SELinux filesystem <tt>/sys/fs/selinux</tt>.
* The SELinux filesystem <tt>/selinux</tt>.
+
# The <tt>/proc</tt> filesystem area most applicable to SELinux.
* The boot sequences that are relevant to SELinux.
+
  
 
== The LSM Module ==
 
== The LSM Module ==
The LSM is the Linux security framework that allows 3<sup>rd</sup> party access control mechanisms to be linked into the GNU / Linux kernel. Currently there are two 3<sup>rd</sup> party services that utilise the LSM: SELinux and SMACK (Simplified Mandatory Access Control Kernel) that both provide mandatory access control services. Details regarding SMACK can be found at: [http://www.schaufler-ca.com/ http://www.schaufler-ca.com/].
+
The LSM is the Linux security framework that allows 3<sup>rd</sup> party access control mechanisms to be linked into the GNU / Linux kernel. Currently there are five 3<sup>rd</sup> party services that utilise the LSM:  
 +
 
 +
# SELinux - the subject of this Notebook.
 +
# AppArmor is a MAC service based on pathnames and does not require labeling or relabeling of filesystems. See [http://wiki.apparmor.net/ http://wiki.apparmor.net] for details.
 +
# Simplified Mandatory Access Control Kernel (SMACK). See [http://www.schaufler-ca.com/ http://www.schaufler-ca.com/] for details.
 +
# Tomoyo that is a name based MAC and details can be found at [http://sourceforge.jp/projects/tomoyo/docs http://sourceforge.jp/projects/tomoyo/docs].
 +
# Yama extends the DAC support for <tt>ptrace</tt>. See <tt>Documentation/security/Yama.txt</tt> for further details.
 +
 
 +
The basic idea behind LSM is to:
 +
* Insert security function hooks and security data structures in the various kernel services to allow access control to be applied over and above that already implemented via DAC. The type of service that have hooks inserted are shown in Table 5 with an example task and program execution shown in the [[#Fork Walk-thorough | Fork Walk-thorough]] and [[#Process Transition Walk-thorough | Process Transition Walk-thorough]] sections.
 +
* Allow registration and initialisation services for the 3<sup>rd</sup> party security modules.
 +
* Allow process security attributes to be available to userspace services by extending the <tt>/proc</tt> filesystem with a security namespace as shown in Table 2. These are located at:
 +
<pre>
 +
/proc/<self | pid>/attr/<attr>
 +
/proc/<self | pid>/task/<tid>/attr/<attr>
 +
</pre>
 +
 
 +
: Where <tt><nowiki><pid></nowiki></tt> is the process id, <tt><nowiki><tid></nowiki></tt> is the thread id and <tt><nowiki><attr></nowiki></tt> is the entry described in Table 2.
  
The basic idea behind the LSM is to:
+
* Support filesystems that use extended attributes (SELinux uses <tt>security.selinux</tt> as explained in the [[NB_Objects#Labeling_Extended_Attribute_Filesystems | Labeling Extended Attribute Filesystems]] section).
# Insert security function calls (or hooks) and security data structures in the various kernel services to allow access control to be applied over and above that already implemented via DAC. The type of service that have hooks inserted are shown in Table 1 with an example task and program execution shown in the Fork Walk-thorough and Process Transition Walk-thorough sections below.
+
* Consolidate the Linux capabilities into an optional module.
# Allow registration and initialisation services for the 3<sup>rd</sup> party security modules.
+
# Allow process security attributes to be available to userspace services by extending the <tt>/proc</tt> filesystem with a security namespace.
+
# Support filesystems that use extended attributes (SELinux uses <tt>security.selinux</tt>.
+
# Consolidate the Linux capabilities into an optional module.
+
  
 
It should be noted that the LSM does not provide any security services itself, only the hooks and structures for supporting 3<sup>rd</sup> party modules. If no 3<sup>rd</sup> party module is loaded, the capabilities module becomes the default module thus allowing standard DAC access control.
 
It should be noted that the LSM does not provide any security services itself, only the hooks and structures for supporting 3<sup>rd</sup> party modules. If no 3<sup>rd</sup> party module is loaded, the capabilities module becomes the default module thus allowing standard DAC access control.
  
 +
<center>'''Table 1: LSM Hooks - '''''These are the kernel services that LSM has inserted security hooks and structures to allow access control to be managed by 3<sup>rd</sup> party modules (see <tt>./linux-3.14/include/linux/security.h</tt>).''</center>
 
{| border="1"
 
{| border="1"
 
| Program execution
 
| Program execution
Line 51: Line 64:
  
 
|}
 
|}
''Table 1: LSM Hooks - These are the kernel services that LSM has inserted security hooks and structures to allow access control to be managed by 3<sup>rd</sup> party modules (see <tt>./kernel-2.6.27/include/linux/security.h</tt>).''
 
  
The major kernel source files (relative to <tt>./kernel-2.6.27/security</tt>) that form the LSM are shown in Table 2. However there is one major header file (<tt>include/linux/security.h</tt>) that describes all the security hooks and structures defined by the LSM.
 
  
 +
<center>'''Table 2: /proc Filesystem attribute files''' - ''These files are used by the kernel services and libselinux (for userspace) to manage setting and reading of security contexts within the LSM defined data structures.''</center>
 +
{| border="1"
 +
! <center>/proc/self/attr/ File Name</center>
 +
! Permissions
 +
! Function
 +
 +
|-
 +
|  current
 +
|  -rw-rw-rw-
 +
| Contains the current process security context.
 +
 +
|-
 +
|  exec
 +
|  -rw-rw-rw-
 +
| Used to set the security context for the next exec call.
 +
 +
|-
 +
|  fscreate
 +
|  -rw-rw-rw-
 +
| Used to set the security context of a newly created file.
 +
 +
|-
 +
|  keycreate
 +
|  -rw-rw-rw-
 +
| Used to set the security context for keys that are cached in the kernel.
 +
 +
|-
 +
|  prev
 +
|  -r--r--r--
 +
| Contains the previous process security context.
 +
 +
|-
 +
|  sockcreate
 +
|  -rw-rw-rw-
 +
| Used to set the security context of a newly created socket.
 +
 +
|}
 +
 +
 +
The major kernel source files (relative to <tt>./linux-3.14/security</tt>) that form the LSM are shown in Table 7. However there is one major header file (<tt>include/linux/security.h</tt>) that describes all the LSM security hooks and structures.
 +
 +
<center>'''Table 3: The core LSM source modules.'''</center>
 
{| border="1"
 
{| border="1"
 
! Name
 
! Name
Line 61: Line 114:
 
|-
 
|-
 
|  capability.c
 
|  capability.c
| Some capability functions were in various kernel modules have been consolidated into these source files. These are now (from Kernel 2.6.27) always linked into the kernel. This means the dummy.c security module (mentioned in the "[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]" document) is no longer required.
+
| Some capability functions were in various kernel modules have been consolidated into these source files.
  
 
|-
 
|-
Line 71: Line 124:
 
|-
 
|-
 
|  inode.c
 
|  inode.c
| This allows the 3<sup>rd</sup> party security module to initialise a security filesystem. In the case of SELinux this would be <tt>/selinux</tt> that is defined in the <tt>selinux/selinuxfs.c</tt> source file.
+
| This allows the 3<sup>rd</sup> party security module to initialise a security filesystem. In the case of SELinux this would be <tt>/sys/fs/selinux</tt> that is defined in the <tt>selinux/selinuxfs.c</tt> source file.  
 
+
|-
+
|  root_plug.c
+
| This is a sample 3<sup>rd</sup> party module and therefore not used.
+
  
 
|-
 
|-
Line 81: Line 130:
 
| Contains the LSM framework initialisation services that will set up the hooks described in <tt>security.h</tt> and those in the capability source files. It also provides functions to initialise 3<sup>rd</sup> party modules.  
 
| Contains the LSM framework initialisation services that will set up the hooks described in <tt>security.h</tt> and those in the capability source files. It also provides functions to initialise 3<sup>rd</sup> party modules.  
  
|}
+
|-
''Table 2: The core LSM source modules.''
+
|  lsm_audit.c
 +
| Contains common LSM audit functions.
  
 +
|-
 +
|  min_addr.c
 +
| Minimum VM address protection from userspace for DAC and LSM.
 +
 +
|}
  
 
== The SELinux Module ==
 
== The SELinux Module ==
This section does not go into detail of all the SELinux module functionality as the "[http://www.nsa.gov/selinux/papers/module/t1.html Implementing SELinux as a Linux Security Module]" document does this, however it attempts to highlight the way some areas work by using the Fork and Domain Transition Walk-thorough and transition process examples and also by describing the SELinux Boot Process.
+
This section does not go into detail of all the SELinux module functionality as the [http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf Implementing SELinux as a Linux Security Module] does this (although a bit dated), however it attempts to highlight the way some areas work by using the [[#Fork and Domain Transition Walk-thorough | fork and transition process example]] described in the [[NB_Domain_and_Object_Transitions#Domain Transition | Domain Transition]] section.
 +
 
 +
The major kernel SELinux source files (relative to <tt>./linux-3.14/security/selinux</tt>) that form the SELinux security module are shown in Table 4. The diagrams shown in[http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] and [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] can be used to see how some of these kernel source modules fit together.  
  
The major kernel SELinux source files (relative to <tt>./kernel-2.6.27/security/selinux</tt>) that form the SELinux security module are shown in Table 3. The diagrams [http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png High Level SELinux Architecture] and [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] can be used to see how some of these kernel source modules fit together.
+
<center>'''Table 4: The core SELinux source modules - '''''The <tt>.h</tt> files and those in the <tt>include</tt> directory have a number of useful comments.''</center>
  
 
{| border="1"
 
{| border="1"
Line 96: Line 153:
 
|-
 
|-
 
|  avc.c
 
|  avc.c
| Access Vector Cache functions and structures. The function calls are for the kernel services, however they have been ported to form the <tt>libselinux</tt> userspace library detailed in the [[LibselinuxAPISummary | API Summary for libselinux]] section.
+
| Access Vector Cache functions and structures. The function calls are for the kernel services, however they have been ported to form the <tt>libselinux</tt> userspace library.
  
 
|-
 
|-
Line 108: Line 165:
 
|-
 
|-
 
|  netif.c
 
|  netif.c
| These manage the mapping between labels and SIDs for the net* language statements when they are declared in the active policy.
+
| These manage the mapping between labels and SIDs for the <tt>net</tt><nowiki>* language statements when they are declared in the active policy.</nowiki>
  
 
|-
 
|-
Line 129: Line 186:
 
|-
 
|-
 
|  selinuxfs.c
 
|  selinuxfs.c
| The <tt>selinuxfs</tt> pseudo filesystem (<tt>/selinux</tt>) that exports the security policy to userspace services via <tt>libselinux</tt>. The services exported are shown in the SELinux Filesystem section below.
+
| The <tt>selinuxfs</tt> pseudo filesystem (<tt>/sys/fs/selinux</tt>) that imports/exports security policy information to/from userspace services. The services exported are shown in the [[#SELinux Filesystem | SELinux Filesystem]] section.
  
 
|-
 
|-
 
|  xfrm.c
 
|  xfrm.c
| Contains the IPSec XFRM hooks for SELinux.
+
| Contains the IPSec XFRM (transform) hooks for SELinux.
  
 
|-
 
|-
|  include/flask.h
+
|  include/classmap.h
| This contains all the kernel security classes and initial SIDs. Note that the Reference Policy source (<tt>policy/flask</tt> directory) contains a list of all the kernel and userspace security classes and permissions.  
+
| <tt>classmap.h</tt> contains all the kernel security classes and permissions. <tt>initial_sid_to_string.h</tt> contains the initial SID contexts. These are used to build the <tt>flask.h</tt> and <tt>av_permissions.h</tt> kernel configuration files when the kernel is being built (using the <tt>genheaders</tt> script defined in the <tt>selinux/Makefile</tt>).
 +
 
 +
These files are built this way now to support the new dynamic security class mapping structure to remove the need for fixed class to SID mapping.
 +
 
 +
|-
 +
|  include/initial_sid_to_string.h
  
 
|-
 
|-
Line 146: Line 208:
 
|  ss/conditional.c
 
|  ss/conditional.c
 
| Support boolean statement functions and implements a conditional AV table to hold entries.
 
| Support boolean statement functions and implements a conditional AV table to hold entries.
 
|-
 
|  ss/avtab.c
 
| AVC table functions for inserting / deleting entries.
 
  
 
|-
 
|-
Line 169: Line 227:
 
|-
 
|-
 
|  ss/services.c
 
|  ss/services.c
| This contains the supporting services for kernel hooks defined in hooks.c, the AVC and the Security Server.  
+
| This contains the supporting services for kernel hooks defined in <tt>hooks.c</tt>, the AVC and the Security Server.  
  
For example the <tt>security_transition_sid</tt> that computes the SID for a new subject / object shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram.
+
For example the <tt>security_transition_sid</tt> that computes the SID for a new subject / object shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram.
  
 
|-
 
|-
 
|  ss/sidtab.c
 
|  ss/sidtab.c
 
| The SID table contains the security context indexed by its SID value.
 
| The SID table contains the security context indexed by its SID value.
 +
 +
|-
 +
|  ss/status.c
 +
| Interface for <tt>selinuxfs/status</tt>. Used by the <tt>libselinux</tt> <tt>selinux_status_*(3)</tt> functions.
  
 
|-
 
|-
Line 182: Line 244:
  
 
|}
 
|}
'''Table 3: The core SELinux source modules - '''''The <tt>.h</tt> files and those in the <tt>include</tt> directory have a number of useful comments.''
+
 
  
  
 
=== Fork System Call Walk-thorough ===
 
=== Fork System Call Walk-thorough ===
This section walks through the the <tt>fork</tt> system call shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram starting at the kernel hooks that link to the SELinux services. The way the SELinux hooks are initialised into the LSM <tt>security_ops</tt> and <tt>secondary_ops</tt> function tables are also described.
+
This section walks through the the <tt>'''fork'''(2)</tt> system call shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram starting at the kernel hooks that link to the SELinux services. The way the SELinux hooks are initialised into the LSM <tt>security_ops</tt> function table are also described.
 
+
Using the [http://taiga.selinuxproject.org/~rhaines/diagrams/10-Fork.png Hooks for the fork system call] diagram, the major steps to check whether the <tt>unconfined_t</tt> process has permission to use the fork permission are:
+
  
 +
Using the [http://selinuxproject.org/~rhaines/NB4-diagrams/10-fork.png hooks for a fork] diagram, the major steps to check whether the <tt>unconfined_t</tt> process has permission to use the fork permission are:
 
# The <tt>kernel/fork.c</tt> has a hook that links it to the LSM function <tt>security_task_create()</tt> that is called to check access permissions.  
 
# The <tt>kernel/fork.c</tt> has a hook that links it to the LSM function <tt>security_task_create()</tt> that is called to check access permissions.  
 
# Because the SELinux module has been initialised as the security module, the <tt>security_ops</tt> table has been set to point to the SELinux <tt>selinux_task_create()</tt> function in <tt>hooks.c</tt>.
 
# Because the SELinux module has been initialised as the security module, the <tt>security_ops</tt> table has been set to point to the SELinux <tt>selinux_task_create()</tt> function in <tt>hooks.c</tt>.
# The <tt>selinux_task_create()</tt> function will first call the capabilities code in <tt>capability.c</tt> via the <tt>secondary_ops</tt> function table to check the DAC permission.
+
# The <tt>selinux_task_create()</tt> function check whether the task has permission via the <tt>current_has_perm(current, PROCESS__FORK)</tt> function.  
# This is simply a <tt>return 0;</tt>, therefore no error would be generated.
+
# This will result in a call to the AVC via the <tt>avc_has_perm()</tt> function in <tt>avc.c</tt> that checks whether the permission has been granted or not. First (via <tt>avc_has_perm_noaudit()</tt>) the cache is checked for an entry. Assuming that there is no entry in the AVC, then the <tt>security_compute_av()</tt> function in <tt>services.c</tt> is called.
# The <tt>selinux_task_create()</tt> function will then check whether the task has permission via the <tt>task_has_perm(current_process, current_process, PROCESS__FORK)</tt> function.  
+
# The <tt>security_compute_av()</tt> function will search the SID table for source and target entries, and if found will then call the <tt>context_struct_compute_av()</tt> function. The <tt>context_struct_compute_av()</tt> function carries out many checks to validate whether access is allowed. The steps are (assuming the access is valid):
# This will result in a call to the AVC via the <tt>avc_has_perm()</tt> function in <tt>avc.c</tt> that checks whether the permission has been granted or not. First (via <tt>avc_has_perm_noaudit()</tt>) the cache is checked to for an entry. Assuming that there is no entry in the AVC, then the <tt>security_compute_av()</tt> function in <tt>services.c</tt> is called.
+
## Initialise the AV structure so that it is clear.
# The <tt>security_compute_av()</tt> function will search the SID table for source and target entries, and if found will then call the <tt>context_struct_compute_av()</tt> function.
+
## Check the object class and permissions are correct. It also checks the status of the <tt>allow_unknown</tt> flag (see the [[#SELinux Filesystem | SELinux Filesystem]], <tt>[[GlobalConfigurationFiles#/etc/selinux/semanage.conf | /etc/selinux/semanage.conf]]</tt> file and<tt> </tt>[[NB_RefPolicy#Build Options | Reference Policy Build Options - build.conf UNK_PERMS]] sections).
: The <tt>context_struct_compute_av()</tt> function carries out many check to validate whether access is allowed. The steps are (assuming the access is valid):
+
## Checks if there are any type enforcement rules (<tt>ALLOW</tt>, <tt>AUDIT_ALLOW</tt>, <tt>AUDIT_DENY</tt>).
:: a) Initialise the AV structure so that it is clear.
+
## Check whether any conditional statements are involved via the <tt>cond_compute_av()</tt> function in <tt>conditional.c</tt>.
:: b) Check the object class and permissions are correct. It also checks the status of the <tt>allow_unknown</tt> flag (see the SELinux Filesystem section below, [[GlobalConfigurationFiles | /etc/selinux/semanage.conf file]] and [[NB_RefPolicy | Reference Policy Build Options - build.conf]] sections).
+
## Remove permissions that are defined in any constraint via the <tt>constraint_expr_eval()</tt> function call (in <tt>services.c</tt>). This function will also check any MLS constraints.
:: c) Checks if there are any type enforcement rules (<tt>ALLOW</tt>, <tt>AUDIT_ALLOW</tt>, <tt>AUDIT_DENY</tt>).
+
## <tt>context_struct_compute_av()</tt> checks if a process transition is being requested (it is not). If it were, then the <tt>TRANSITION</tt> and <tt>DYNTRANSITION</tt> permissions are checked and whether the role is changing.
:: d) Check whether any conditional statements are involved via the <tt>cond_compute_av()</tt> function in <tt>conditional.c</tt>.
+
## Finally check whether there are any constraints applied via the <tt>typebounds</tt> rule.  
:: e) Remove permissions that are defined in any constraint via the <tt>constraint_expr_eval()</tt> function call (in <tt>services.c</tt>). This function will also check any MLS constraints.
+
# Once the result has been computed it is returned to the <tt>kernel/fork.c</tt> system call via the initial <tt>selinux_task_create()</tt> function. In this case the <tt>fork</tt> call is allowed.  
:: f) Finally <tt>context_struct_compute_av()</tt> checks if a process transition is being requested (it is not). If it were, then the <tt>TRANSITION</tt> and <tt>DYNTRANSITION</tt> permissions are checked and whether the role is changing.
+
# The End.
: 8. Once the result has been computed it is returned to the <tt>kernel/fork.c</tt> system call via the initial <tt>selinux_task_create()</tt> function. In this case the fork call is allowed.  
+
 
: 9. The End.
+
  
 
=== Process Transition Walk-thorough ===
 
=== Process Transition Walk-thorough ===
This section walks through the <tt>execve()</tt> and checking whether a process transition to the <tt>ext_gateway_t</tt> domain is allowed, and if so obtain a new SID for the context (<tt>user_u:message_filter_r:ext_gateway_t</tt>) as shown in the [http://taiga.selinuxproject.org/~rhaines/diagrams/7-domain-transition.png Domain Transition] diagram.
+
This section walks through the <tt>'''execve'''(2)</tt> and checking whether a process transition to the <tt>ext_gateway_t</tt> domain is allowed, and if so obtain a new SID for the context (<tt>unconfined_u:message_filter_r:ext_gateway_t</tt>) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram.
  
The process starts with the Linux operating system issuing a <tt>do_execve()<ref name="ftn16"><tt>This function call will pass over the file name to be run and its environment + arguments. Note that for loading shared libraries the exec_mmap function is used.</tt></ref> call from the CPU specific architecture code to execute a new program (for example, from <tt>arch/ia64/kernel/process.c</tt>). The <tt>do_execve()</tt> function is located in the <tt>fs/exec.c</tt> source code module and does the loading and final exec as described below.
+
The process starts with the Linux operating system issuing a <tt>do_execve<ref name="ftn14">This function call will pass over the file name to be run and its environment + arguments.</ref> call from the CPU specific architecture code to execute a new program (for example, from <tt>arch/ia64/kernel/process.c</tt>). The <tt>do_execve()</tt> function is located in the <tt>fs/exec.c</tt> source code module and does the loading and final exec as described below.
  
<tt>do_execve()</tt> has a number of calls to <tt>security_bprm_*</tt> functions that are a part of the LSM (see <tt>security.h</tt>), and are hooked by SELinux during the initialisation process (in <tt>hooks.c</tt>). Table 4 briefly describes these <tt>security_bprm</tt> functions that are hooks for validating program loading and execution (although see <tt>security.h</tt> for greater detail).
+
<tt>do_execve()</tt> has a number of calls to <tt>security_bprm_*</tt> functions that are a part of the LSM (see <tt>include/linux</tt>/<tt>security.h</tt>), and are hooked by SELinux during the initialisation process (in <tt>security/selinux</tt>/<tt>hooks.c</tt>). Table 5 briefly describes these <tt>security_bprm</tt> functions that are hooks for validating program loading and execution (although see <tt>security.h</tt> for greater detail).
  
 +
<center>'''Table 5: The LSM / SELinux Program Loading Hooks'''</center>
 
{| border="1"
 
{| border="1"
 
| '''LSM / SElinux Function Name'''
 
| '''LSM / SElinux Function Name'''
Line 219: Line 280:
  
 
|-
 
|-
<nowiki>security_bprm_alloc->
+
security_bprm_set_creds->
 +
  
  selinux_bprm_alloc_security</nowiki>
+
  selinux_bprm_set_creds
| Allocates memory for the <tt>bprm</tt> structure.
+
| Set up security information in the <tt>bprm->security</tt> field based on the file to be exec'ed contained in <tt>bprm->file</tt>. SELinux uses this hook to check for domain transitions and the whether the appropriate permissions have been granted, and obtaining a new SID if required.
  
 
|-
 
|-
<nowiki>security_bprm_free->
+
security_bprm_committing_creds->
 +
  
  selinux_bprm_free_security</nowiki>
+
  selinux_bprm_committing_creds
| Frees memory from the <tt>bprm</tt> structure.
+
| Prepare to install the new security attributes of the process being transformed by an execve operation. SELinux uses this hook to close any unauthorised files, clear parent signal and reset resource limits if required.
  
 
|-
 
|-
<nowiki>security_bprm_apply_creds->
+
security_bprm_committed_creds->
 +
  
  selinux_bprm_apply_creds</nowiki>
+
  selinux_bprm_ committed_creds
| Sets task lock and new security attributes for a transformed process on execve. Seems to be used for libraries, scripts etc. Called from various Linux OS areas via <tt>compute_creds()</tt> located in <tt>fs/exec.c</tt>.
+
| Tidy up after the installation of the new security attributes of a process being transformed by an <tt>execve</tt> operation. SELinux uses this hook to check whether signal states can be inherited if new SID allocated.
  
 
|-
 
|-
<nowiki>security_bprm_post_apply_creds->
+
security_bprm_secureexec->
 +
  
  selinux_bprm_post_apply_creds</nowiki>
+
  selinux_bprm_secureexec
| Supports the <tt>security_bprm_apply_creds</tt> function for areas that must not be locked.
+
| Called when loading libraries to check <tt>AT_SECURE</tt> flag for glibc secure mode support. SELinux uses this hook to check the <tt>process</tt> class <tt>noatsecure</tt> permission if appropriate.
  
 
|-
 
|-
<nowiki>security_bprm_secureexec->
+
security_bprm_check->
 +
  
selinux_bprm_secureexec</nowiki>
+
  selinux_bprm_check_security
| Called after the <tt>selinux_bprm_post_apply_creds</tt> function to check <tt>AT_SECURE</tt> flag for glibc secure mode support.
+
 
+
|-
+
|  <nowiki>security_bprm_set->
+
 
+
selinux_bprm_set_security</nowiki>
+
| Carries out the major checks to validate whether the process can transition to the target context, and obtain a new SID if required.
+
 
+
|-
+
|  <nowiki>security_bprm_check->
+
 
+
  selinux_bprm_check_security</nowiki>
+
 
| This hook is not used by SELinux.
 
| This hook is not used by SELinux.
  
 
|}
 
|}
''Table 4: The LSM / SELinux Program Loading Hooks''
 
  
  
Therefore starting at the <tt>do_execve()</tt> function and using the [http://taiga.selinuxproject.org/~rhaines/diagrams/11-Transition.png Process Transition] diagram, the following major steps will be carried out to check whether the <tt>unconfined_t</tt> process has permission to transition the <tt>secure_server</tt> executable to the <tt>ext_gateway_t</tt> domain:
+
Therefore starting at the <tt>do_execve()</tt> function and using the [http://selinuxproject.org/~rhaines/NB4-diagrams/11-transition.png Process Transition] diagram, the following major steps will be carried out to check whether the <tt>unconfined_t</tt> process has permission to transition the <tt>secure_server</tt> executable to the <tt>ext_gateway_t</tt> domain:
 +
# The executable file is opened, a call issued to the <tt>sched_exec()</tt> function and the <tt>bprm</tt> structure is initialised with the file parameters (name, environment and arguments).
 +
# Via the <tt>prepare_binprm()</tt> function call the UID and GIDs are checked and a call issued to <tt>security_bprm_set_creds()</tt> that will carry out the following:
 +
# Call <tt>cap_bprm_set_creds</tt> function in <tt>commoncap.c</tt>, that will set up credentials based on any configured capabilities. If <tt>'''setexeccon'''(3)</tt> has been called prior to the exec, then that context will be used otherwise call <tt>security_transition_sid()</tt> function in <tt>services.c</tt>. This function will then call <tt>security_compute_sid()</tt> to check whether a new SID needs to be computed. This function will (assuming there are no errors):
 +
## Search the SID table for the source and target SIDs.
 +
## Sets the SELinux user identity.
 +
## Set the source role and type.
 +
## Checks that a <tt>type_transition</tt> rule exists in the AV table and / or the conditional AV table (see the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram).
 +
## If a <tt>type_transition</tt>, then also check for a <tt>role_transition</tt> (there is a role change in the <tt>ext_gateway.conf</tt> policy module), set the role.
 +
## Check if any MLS attributes by calling <tt>mls_compute_sid()</tt> in <tt>mls.c</tt>. It also checks whether MLS is enabled or not, if so sets up MLS contexts.
 +
## Check whether the contexts are valid by calling <tt>compute_sid_handle_invalid_context()</tt> that will also log an audit message if the context is invalid.
 +
## Finally obtains a SID for the new context by calling <tt>sidtab_context_to_sid()</tt> in <tt>sidtab.c</tt> that will search the SID table (see the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram) and insert a new entry if okay or log a kernel event if invalid.
 +
# The <tt>selinux_bprm_set_creds()</tt> function will continue by checking via the <tt>avc_has_perm()</tt> functions (in <tt>avc.c</tt>) whether the <tt>file</tt> class <tt>file_execute_no_trans</tt> is set (in this case it is not), therefore the <tt>process</tt> class <tt>transition</tt> and <tt>file</tt> class <tt>file_entrypoint</tt> permissions are checked (in this case they are allowed), therefore the new SID is set, and after checking various other permissions, control is passed back to the <tt>do_execve</tt> function.
 +
# The <tt>exec_binprm</tt> function will ultimately commit the credentials calling the SELinux <tt>selinux_bprm_committing_creds</tt> and <tt>selinux_bprm_committed_creds</tt>.
 +
# Various strings are copied (args etc.) and a check is made to see if the exec succeeded or not (in this case it did), therefore the <tt>security_bprm_free()</tt> function is ultimately called to free the <tt>bprm</tt> security structure.
 +
# The End.
 +
 
  
: 1. The executable file is opened, a call issued to the <tt>sched_exec()</tt> function and the <tt>bprm</tt> structure is initialised with the file parameters (name, environment and arguments).
 
: The <tt>security_bprm_alloc()->selinux_bprm_alloc_security()</tt> function is then called (in <tt>hooks.c</tt>) where SELinux will allocate memory for the <tt>bprm</tt> security structure and set the <tt>bsec->set</tt> flag to <tt>0</tt> indicating this is the first time through this process for this exec request.
 
: 2. Via the <tt>prepare_binprm()</tt> function call the UID and GIDs are checked and a call issued to <tt>security_bprm_set()</tt> that will carry out the following:
 
:: a) The <tt>selinux_bprm_set_security()</tt> function will call the <tt>secondary_ops->bprm_set_security</tt> function in <tt>capability.c</tt>, that is effectively a no-op.
 
:: b) The <tt>bsec->set</tt> flag will be checked and if <tt>1</tt> will return as this function can be called multiple times during the exec process.
 
:: c) The target SID is checked to see whether a transition is required (in this case it is), therefore a call will be made to the <tt>security_transition_sid()</tt> function in <tt>services.c</tt>. This function will compute the SID for a new subject or object (subject in this case) via the <tt>security_compute_sid()</tt> function that will (assuming there are no errors):
 
::: .i.  Search the SID table for the source and target SIDs.
 
::: .ii.  Sets the SELinux user identity.
 
::: .iii. Set the source role and type.
 
::: .iv.  Checks that a <tt>type_transition</tt> rule exists in the AV table and / or the conditional AV table (see the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram).
 
::: .v.  If a <tt>type_transition</tt>, then also check for a <tt>role_transition</tt> (there is a role change in the <tt>ext_gateway.conf</tt> policy module), set the role.
 
::: .vi.  Check if any MLS attributes by calling <tt>mls_compute_sid()</tt> in <tt>mls.c</tt>. It also checks whether MLS is enabled or not, if so sets up MLS contexts.
 
::: .vii. Check whether the contexts are valid by calling <tt>compute_sid_handle_invalid_context()</tt> that will also log an audit message if the context is invalid.
 
::: .viii. Finally obtains a SID for the new context by calling <tt>sidtab_context_to_sid()</tt> in <tt>sidtab.c</tt> that will search the SID table (see the [http://taiga.selinuxproject.org/~rhaines/diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram) and insert a new entry if okay or log a kernel event if invalid.
 
:: d) The <tt>selinux_bprm_set_security()</tt> function will then continue by checking via the <tt>avc_has_perm()</tt> function (in <tt>avc.c</tt>) whether the <tt>file_execute_no_trans</tt> is set (in this case it is not), therefore the <tt>process_transition</tt> and <tt>file_entrypoint</tt> permissions are checked (in this case they are), therefore the new SID is set, the <tt>bsec->set</tt> flag is set to <tt>1</tt> so that this part of the function is not executed again for this <tt>exec</tt>, finally control is passed back to the <tt>do_execve</tt> function:
 
: 3. Various strings are copied (args etc.) and a check is made to see if the exec succeeded or not (in this case it did), therefore the <tt>security_bprm_free()</tt> function is called to free the <tt>bprm</tt> security structure.
 
: 4. The End.
 
  
 
=== SELinux Filesystem ===
 
=== SELinux Filesystem ===
Table 5 shows the information contained in the pseudo file system /selinux where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the [[LibselinuxAPISummary | libselinux API]] library (that is used by user-space object managers and SELinux-aware applications).
+
Table 6 shows the information contained in the SELinux filesystem (<tt>selinuxfs</tt>) /sys/fs/selinux (or /selinux on older systems) where the SELinux kernel exports information regarding its configuration and active policy. <tt>selinuxfs</tt> is a read/write interface used by SELinux library functions for userspace SELinux-aware applications and object managers. Note: while it is possible for userspace applications to read/write to this interface, it is not recommended - use the libselinux library.
  
 +
<center>'''Table 6: selinux filesystem Information'''</center>
 
{| border="1"
 
{| border="1"
! <center>Directory / File Name</center>
+
! <center>selinuxfs Directory and File Names</center>
 
! <center>Permissions</center>
 
! <center>Permissions</center>
 
! <center>Comments</center>
 
! <center>Comments</center>
  
 
|-
 
|-
| '''/selinux'''
+
| '''/sys/fs/selinux'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
| This is the root directory where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the libselinux library (that is used by user space object managers and SELinux-aware applications).
+
| This is the root directory where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the libselinux library.
  
 
|-
 
|-
 
| <div align="right">access</div>
 
| <div align="right">access</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Compute access decision interface.
+
| Compute access decision interface that is used by the <tt>'''security_compute_av'''(3)</tt>,<tt> '''security_compute_av_flags'''(3)</tt>, <tt>'''avc_has_perm'''(3)</tt>and <tt>'''avc_has_perm_noaudit'''(3)</tt> functions.
 +
 
 +
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_compute_av_user</tt> function to compute the new SID that is then converted to a context string.
 +
 
 +
Requires <tt>security {compute_av}</tt> permission.
  
 
|-
 
|-
 
| <div align="right">checkreqprot</div>
 
| <div align="right">checkreqprot</div>
 
| <center>-rw-r--r--</center>
 
| <center>-rw-r--r--</center>
| Check requested protection, not kernel-applied one.
+
| <tt>0</tt> = Check requested protection applied by kernel.
 +
 
 +
<tt>1</tt> = Check protection requested by application. This is the default.
 +
 
 +
These apply to the <tt>mmap</tt> and <tt>mprotect</tt> kernel calls. Default value can be changed at boot time via the <tt>checkreqprot=</tt> parameter.
 +
 
 +
Requires <tt>security {setcheckreqprot}</tt> permission.
  
 
|-
 
|-
Line 312: Line 375:
 
| Commit new boolean values to the kernel policy.
 
| Commit new boolean values to the kernel policy.
  
|-
+
Requires <tt>security {setbool}</tt> permission.
| <div align="right">compat_net</div>
+
| <center>-rw-r--r--</center>
+
| Whether SECMARK is enabled or not:
+
 
+
0 = SECMARK enabled (F-12 default).
+
 
+
1 = SECMARK disabled
+
 
+
  
 
|-
 
|-
 
| <div align="right">context</div>
 
| <div align="right">context</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Validate context interface.
+
| Validate context interface used by the <tt>'''security_check_context'''(3)</tt> function.
 +
 
 +
Requires <tt>security {check_context}</tt> permission.
  
 
|-
 
|-
 
| <div align="right">create</div>
 
| <div align="right">create</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Compute create labeling decision interface.
+
| Compute create labeling decision interface that is used by the <tt>'''security_compute_create'''(3)</tt> and <tt>'''avc_compute_create'''(3)</tt> functions.
 +
 
 +
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_transition_sid_user</tt> function to compute the new SID that is then converted to a context string.
 +
 
 +
Requires <tt>security {compute_create}</tt> permission.
  
 
|-
 
|-
 
| <div align="right">deny_unknown</div>
 
| <div align="right">deny_unknown</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| These two files export unknown deny and reject handling status to user space. This is taken from the handle-unknown parameter set<ref name="ftn17"><sup>That is taken from the UNK_PERMS entry in the Reference Policy build.conf file.</sup></ref> in the /etc/selinux/semanage.conf file and are set as follows:
+
| These two files export deny_unknown (read by <tt>'''security_deny_unknown'''(3)</tt> function) and reject_unknown status to user space.  
 +
 
 +
These are taken from the handle-unknown parameter set<ref name="ftn15"><sup>This is also set in the UNK_PERMS entry of the Reference Policy [#_Reference_Policy_Build_Options (bui build.conf] file. The entry in <tt>semanage.conf</tt> will over-ride the <tt>build.conf</tt> entry.</sup></ref> in the <tt>/etc/selinux/semanage.conf</tt> file when policy is being built and are set as follows:
 +
 
 +
deny:reject
 +
 
 +
0:0 = Allow unknown object class / permissions. This will set the returned AV with all 1's.
 +
 
 +
1:0 = Deny unknown object class / permissions (the default). This will set the returned AV with all 0's.
  
0:0 = allow, 1:0 = deny and 1:1 = reject.
+
1:1 = Reject loading the policy if it does not contain all the object classes / permissions.
  
 
|-
 
|-
Line 351: Line 420:
 
| <div align="right">enforce</div>
 
| <div align="right">enforce</div>
 
| <center>-rw-r--r--</center>
 
| <center>-rw-r--r--</center>
| Get or set enforcing status. Used by the setenforce(8) command.
+
| Get or set enforcing status.
 +
 
 +
Requires <tt>security {setenforce}</tt> permission.
  
 
|-
 
|-
Line 357: Line 428:
 
| <center>-rw-------</center>
 
| <center>-rw-------</center>
 
| Load policy interface.
 
| Load policy interface.
 +
 +
Requires <tt>security {load_policy}</tt> permission.
  
 
|-
 
|-
 
| <div align="right">member</div>
 
| <div align="right">member</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Compute polyinstantiation membership decision interface.
+
| Compute polyinstantiation membership decision interface that is used by the <tt>'''security_compute_member'''(3)</tt> and <tt>'''avc_compute_member'''(3)</tt> functions.
 +
 
 +
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_member_sid</tt> function to compute the new SID that is then converted to a context string.
 +
 
 +
Requires <tt>security {compute_member}</tt> permission.
  
 
|-
 
|-
Line 371: Line 448:
 
| <div align="right">null</div>
 
| <div align="right">null</div>
 
| <center>crw-rw-rw-</center>
 
| <center>crw-rw-rw-</center>
|  
+
| The SELinux equivalent of <tt>/dev/null</tt> for file descriptors that have been redirected by SELinux.
 +
 
 +
|-
 +
| <div align="right">policy</div>
 +
| <center>-r--r--r--</center>
 +
| Interface to upload the current running policy in kernel binary format. This is useful to check the running policy using <tt>'''apol'''(1)</tt> , <tt>dispol</tt>/<tt>sedispol</tt> etc. (e.g. <tt>cat /sys/fs/selinux/policy > current-policy</tt> then load it into the required tool).
  
 
|-
 
|-
 
| <div align="right">policyvers</div>
 
| <div align="right">policyvers</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| Returns policy version for this kernel (F-12 = 24).
+
| Returns supported policy version for kernel. Read by <tt>'''security_policyvers'''(3)</tt> function.
  
 
|-
 
|-
 
| <div align="right">relabel</div>
 
| <div align="right">relabel</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Compute relabeling decision interface.
+
| Compute relabeling decision interface that is used by the <tt>'''security_compute_relabel'''(3)</tt> function.
 +
 
 +
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_change_sid</tt> function to compute the new SID that is then converted to a context string.
 +
 
 +
Requires <tt>security {compute_relabel}</tt> permission.
 +
 
 +
|-
 +
| <div align="right">status</div>
 +
| <center>-r--r--r--</center>
 +
| This can be used to obtain enforcing mode and policy load changes with much less over-head than using the <tt>libselinux</tt> netlink / call backs. This was added for Object Managers that have high volumes of AVC requests so they can quickly check whether to invalidate their cache or not.
 +
 
 +
The status structure indicates the following:
 +
 
 +
<tt>version</tt> - Version number of the status structure. This will increase as other entries are added.
 +
 
 +
<tt>sequence</tt> - This is incremented for each event with an even number meaning that the events are stable. An odd number indicates that one of the events is changing and therefore the userspace application should wait before reading the status of any event.
 +
 
 +
<tt>enforcing</tt> - <tt>0</tt> = Permissive mode, <tt>1</tt> = enforcing mode.
 +
 
 +
<tt>policyload</tt> - This contains the policy load sequence number and should be read and stored, then compared to detect a policy reload.
 +
 
 +
<tt>deny_unknown</tt> - <tt>0</tt> = Allow and <tt>1</tt> = Deny unknown object classes / permissions. This is the same as the <tt>deny_unknown</tt> entry above.
  
 
|-
 
|-
 
| <div align="right">user</div>
 
| <div align="right">user</div>
 
| <center>-rw-rw-rw-</center>
 
| <center>-rw-rw-rw-</center>
| Compute reachable user contexts interface.
+
| Compute reachable user contexts interface that is used by the <tt>'''security_compute_user'''(3)</tt> function.
 +
 
 +
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_get_user_sids</tt> function to compute the user SIDs that are then converted to context strings.
 +
 
 +
Requires <tt>security {compute_user}</tt> permission.
  
 
|-
 
|-
| '''/selinux/avc'''
+
| '''/sys/fs/selinux/avc'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
 
| This directory contains information regarding the kernel AVC that can be displayed by the avcstat command.
 
| This directory contains information regarding the kernel AVC that can be displayed by the avcstat command.
Line 396: Line 503:
 
| <div align="right">cache_stats</div>
 
| <div align="right">cache_stats</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| Shows the AVC lookups, hits, misses etc.
+
| Shows the kernel AVC lookups, hits, misses etc.
  
 
|-
 
|-
Line 404: Line 511:
  
 
  echo 0 > /selinux/avc/cache_threshold
 
  echo 0 > /selinux/avc/cache_threshold
 +
 +
Requires <tt>security {setsecparam}</tt> permission.
  
 
|-
 
|-
 
| <div align="right">hash_stats</div>
 
| <div align="right">hash_stats</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| Shows the number of AVC entries, longest chain etc.
+
| Shows the number of kernel AVC entries, longest chain etc.
  
 
|-
 
|-
| '''/selinux/booleans'''
+
| '''/sys/fs/selinux/booleans'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
 
| This directory contains one file for each boolean defined in the active policy.
 
| This directory contains one file for each boolean defined in the active policy.
Line 422: Line 531:
 
<div align="right">......</div>
 
<div align="right">......</div>
 
| <center>-rw-r--r--</center>
 
| <center>-rw-r--r--</center>
| Each file contains the current status of the boolean (0 = false or 1 = true). The getsebool(8), setsebool(8) and sestatus -b commands use this information.
+
| Each file contains the current and pending status of the boolean (0 = false or 1 = true). The '''getsebool'''(8), '''setsebool'''(8) and '''sestatus'''(8)''' -b''' commands use this interface via the <tt>libselinux</tt> library functions.
  
 
|-
 
|-
| '''/selinux/initial_contexts'''
+
| '''/sys/fs/selinux/initial_contexts'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
| This directory contains one file for each initial SID defined in the active policy.
+
| This directory contains one file for each initial SID defined in the active policy. The file name is the initial SID name with the contents containing its security context.
  
 
|-
 
|-
Line 439: Line 548:
  
 
|-
 
|-
| '''/selinux/policy_capabilities'''
+
| '''/sys/fs/selinux/policy_capabilities'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
| This directory contains the policy capabilities that have been configured by default in the kernel. They are generally new features that can be enabled for testing by using the policycap statement in a monolithic or base policy.
+
| This directory contains the policy capabilities that have been configured by default in the kernel via the <tt>policycap</tt> statement in the active policy. These are generally new features that can be enabled by using the policycap statement in policy. Their default values are false.
 +
 
 +
|-
 +
| <div align="right">always_check_network</div>
 +
| <center>-r--r--r--</center>
 +
| If true SECMARK and peer labeling are always enabled even if there are no SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of the <tt>packet</tt> class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.14 minimum.
  
 
|-
 
|-
 
| <div align="right">network_peer_controls</div>
 
| <div align="right">network_peer_controls</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| For the F-12 kernel, this file contains "0" (false) which means that the following network_peer_controls are not enabled by default:
+
| If true the following network_peer_controls are enabled:
  
 
node: sendto recvfrom
 
node: sendto recvfrom
Line 453: Line 567:
  
 
peer: recv
 
peer: recv
 
 
  
 
|-
 
|-
 
| <div align="right">open_perms</div>
 
| <div align="right">open_perms</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| For the F-12 kernel, this file contains "0" (false) which means that open permissions are not enabled by default on the following objects: dir, file, fifo_file, chr_file, blk_file.
+
| If true the open permissions are enabled by default on the following object classes: dir, file, fifo_file, chr_file, blk_file.
  
 
|-
 
|-
| '''/selinux/class'''
+
| <div align="right">redhat1</div>
 +
| <center>-r--r--r--</center>
 +
| Available in kernel 3.4 to allow finer control of <tt>ptrace</tt> (this will be named correctly one day). Requires policy support and the <tt>security</tt> class permission <tt>ptrace_child</tt>.
 +
 
 +
|-
 +
| '''/sys/fs/selinux/class'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
| This directory contains a list of classes and their permissions as defined within the policy.
+
| This directory contains a list of classes and their permissions as defined by the policy (for the Reference Policy the order in the <tt>security_classes</tt> and <tt>access_vectors</tt> files).
  
 
|-
 
|-
| '''/selinux/class/appletalk_socket'''
+
| '''/sys/fs/selinux/class/appletalk_socket'''
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
| Each class has its own directory that contains the following:  
+
| Each class has its own directory where each one is named using the appropriate class statement from the policy (i.e. <tt>class appletalk_socket</tt>). Each directory contains the following:  
  
 
|-
 
|-
 
| <div align="right">index</div>
 
| <div align="right">index</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| This file contains the allocated class number (e.g. appletalk_socket is "56" in flask.h (linux-2.6.27/security/selinux/include/flask.h)).
+
| This file contains the allocated class number (e.g. appletalk_socket is the 56<sup>th</sup> entry in the policy <tt>security_classes</tt> file).
  
 
|-
 
|-
| '''/selinux/class/appletalk_socket/'''
+
| '''/sys/fs/selinux/class/appletalk_socket/perms'''
 
+
'''perms'''
+
 
| <center>'''Directory'''</center>
 
| <center>'''Directory'''</center>
 
| This directory contains one file for each permission defined in the policy.
 
| This directory contains one file for each permission defined in the policy.
Line 492: Line 607:
 
<div align="right">....</div>
 
<div align="right">....</div>
 
| <center>-r--r--r--</center>
 
| <center>-r--r--r--</center>
| Each file contains a number but not sure what it represents.
+
| Each file is named by the permission assigned in the policy and contains a number that represents its position in the list (e.g. <tt>accept</tt> is the 14<sup>th</sup> permission listed in the policy <tt>access_vector</tt> file for the <tt>appletalk_socket</tt> and therefore contains '14'.
  
 
|}
 
|}
''Table 5: /selinux File and Directory Information''
+
 
  
 
Notes:
 
Notes:
 +
# Kernel SIDs are not passed to userspace only the context strings.
 +
# The <tt>/proc</tt> filesystem exports the process security context string to userspace via <tt><nowiki>/proc/<self|pid>/attr</nowiki></tt> and <tt><nowiki>/proc/<self|pid>/task/<tid>/attr/<attr></nowiki></tt> interfaces.
  
# SIDs are not passed to userspace, only the security context string. The context can be read via the  [[LibselinuxAPISummary | libselinux API]] where a userspace object manager normally manages the relationship (see "SELinux Support for Userspace Object Managers" [Ref. 17]).
 
# The <tt>/proc</tt> filesystem exports the process security context string to userspace via <tt>/proc/<pid>/attr</tt> interface (where <tt><pid></tt> is the process ID). These can also be managed via the the  [[LibselinuxAPISummary | libselinux API]].
 
  
=== SELinux Boot Process ===
 
Figure 1 shows the boot process that has been limited to what is considered relevant for initialising SELinux<ref name="ftn18">There is a Linux overview at: [http://en.wikipedia.org/wiki/Linux_startup_process http://en.wikipedia.org/wiki/Linux_startup_process].</ref>, loading the policy and checking whether re-labeling is required. The SELinux kernel initialisation areas are in red. The <tt>kernel</tt>, <tt>mkinitrd</tt> and <tt>upstart</tt> source code rpms were used to find the sequence of events (all corrections welcome).
 
  
 
+
{| style="width: 100%;" border="0"
<center>'''Start Kernel Boot Process'''</center>
+
|-
 
+
| [[NB_PAM | '''Previous''']]
<center>|</center>
+
| <center>[[NewUsers | '''Home''']]</center>
 
+
| <center>[[NB_Userspace_Libraries | '''Next''']]</center>
<center>./init/main.c start_kernel()</center>
+
|}
 
+
<center>|</center>
+
 
+
<center>Load the initial RAM Disk (this is a temporary root filesystem). The source </center>
+
 
+
<center>code for this and <tt>nash(8)</tt> is in the <tt>mkinitrd</tt> source code.</center>
+
 
+
<center>| </center>
+
 
+
<center>Kernel calls <tt>security_init()</tt> to initialise the LSM security framework. </center>
+
 
+
<center>For SELinux this results in a call to <tt>selinux_init()</tt> that is in <tt>hooks.c</tt></center>
+
 
+
<center>|</center>
+
 
+
<center>Set the kernel context to the initial SID value "<tt>1</tt>" taken from</center>
+
 
+
<center><tt>include/flask.h</tt> (<tt>SECINITSID_KERNEL</tt>) </center>
+
 
+
<center>|</center>
+
 
+
<center>The AVC is initialised by a call to <tt>avc_init()</tt></center>
+
 
+
<center>|</center>
+
 
+
<center>Other areas of SELinux get initialised such as the </center>
+
 
+
<center><tt>selinuxfs</tt> (<tt>/selinux</tt>) pseudo filesystem and netlink with their </center>
+
 
+
<center>objects set with the initial SIDs from <tt>flask.h</tt></center>
+
 
+
<center>|</center>
+
 
+
<center><tt>'''/sbin/nash is run by the kernel</tt>.'''</center>
+
 
+
<center>|</center>
+
 
+
<center><tt>/sbin/nash</tt> initialises services such as drivers, loads the root filesystem</center>
+
 
+
<center>read-only and loads the SELinux policy using the <tt>loadPolicyCommand</tt>. </center>
+
 
+
<center>This function will check various directories, then call the SELinux API</center>
+
 
+
<center>the  selinux_init_load_policy function to load the policy.</center>
+
 
+
<center>|</center>
+
 
+
<center>Loading the policy will now complete the SELinux initialisation </center>
+
 
+
<center>with a call to <tt>selinux_complete_init()</tt> in <tt>hooks.c</tt>. </center>
+
 
+
<center>SELinux will now start enforcing policy or allow permissive access </center>
+
 
+
<center>depending on the value set in <tt>/etc/selinux/config SELINUX=</tt></center>
+
 
+
<center>|</center>
+
 
+
<center>The kernel is now loaded, the RAM disk removed, SELinux is </center>
+
 
+
<center>initialised, the policy loaded and <tt>/sbin/init</tt> is running </center>
+
 
+
<center>with the root filesystem in read only mode.</center>
+
 
+
<center>|</center>
+
 
+
<center>'''End Kernel Load and Initialisation'''</center>
+
 
+
<center>|</center>
+
 
+
<center><tt>'''/etc/rc.d/sysinit</tt> is run by <tt>init </tt>that will:'''</center>
+
 
+
<center>|</center>
+
 
+
<center>mount <tt>/proc</tt> and <tt>sysfs</tt> filesystems</center>
+
 
+
<center>|</center>
+
 
+
<center>Check that the <tt>selinuxfs</tt> (<tt>/selinux</tt>) pseudo filesystem</center>
+
 
+
<center>is present and whether the current process is labeled <tt>kernel_t</tt></center>
+
 
+
<center>|</center>
+
 
+
<center>If the current SELinux state can be read (<tt>/selinux/enforce</tt>), </center>
+
 
+
<center>then set to value. If cannot read, set to "1".</center>
+
 
+
<center>|</center>
+
 
+
<center>Run r<tt>estorecon -R</tt> on /<tt>dev</tt> if needed.</center>
+
 
+
<center>|</center>
+
 
+
<center>Kill off <tt>/sbin/nash</tt> if it is still running.</center>
+
 
+
<center>|</center>
+
 
+
<center>Run <tt>restorecon</tt> on <tt>/dev/pts</tt> if needed.</center>
+
 
+
<center>|</center>
+
 
+
<center>Set contexts on the files in <tt>/etc/rwtab</tt> and /<tt>etc/statetab</tt> </center>
+
 
+
<center>by running <tt>restorecon -R path</tt>.</center>
+
 
+
<center>|</center>
+
 
+
<center>Check if relabeling required:</center>
+
 
+
<center>if <tt>./autorelabel</tt> file + <tt>AUTORELABEL=0</tt> (in <tt>/etc/selinux/config</tt>):</center>
+
 
+
<center>then drop to shell for manual relabel, or </center>
+
 
+
<center>if only <tt>./autorelabel</tt> file, then run <tt>fixfiles -F restore</tt>.</center>
+
 
+
<center>|</center>
+
 
+
<center>remove <tt>./autorelabel</tt> file.</center>
+
 
+
<center>|</center>
+
 
+
<center>If <tt>/sbin/init</tt> has changed context after the relabel, </center>
+
 
+
<center>then ensure a reboot. ELSE carry on.</center>
+
 
+
<center>|</center>
+
 
+
<center><tt>/etc/rc.d/sysinit</tt> will do other initialisation tasks, then exit.</center>
+
 
+
<center>|</center>
+
 
+
<center>'''Note:''' Some SELinux notes state that <tt>/sbin/init</tt> is re-exec"ed </center>
+
 
+
<center>to allow it to run in the correct context. Could not find where this</center>
+
 
+
<center>happened as policy seems to be active before <tt>init</tt> daemon is run ?? </center>
+
 
+
<center>|</center>
+
 
+
<center>'''Initialisation Complete'''</center>
+
 
+
''Figure 1: The Boot Sequence - This shows how SELinux is initialised and the policy loaded during the boot process.''
+
  
  
 
----
 
----
 
<references/>
 
<references/>
 +
 +
[[Category:Notebook]]

Latest revision as of 13:58, 25 September 2015

Linux Security Module and SELinux

This section gives a high level overview of the LSM and SELinux internal kernel structure and workings as enabled in kernel 3.14. A more detailed view can be found in the "Implementing SELinux as a Linux Security Module" that was used extensively to develop this section (and also using the SELinux kernel source code). The major areas covered are:

  1. How the LSM and SELinux modules work together.
  2. The major SELinux internal services.
  3. The fork and exec system calls are followed through as an example to tie in with the transition process covered in the Domain Transition section.
  4. The SELinux filesystem /sys/fs/selinux.
  5. The /proc filesystem area most applicable to SELinux.

The LSM Module

The LSM is the Linux security framework that allows 3rd party access control mechanisms to be linked into the GNU / Linux kernel. Currently there are five 3rd party services that utilise the LSM:

  1. SELinux - the subject of this Notebook.
  2. AppArmor is a MAC service based on pathnames and does not require labeling or relabeling of filesystems. See http://wiki.apparmor.net for details.
  3. Simplified Mandatory Access Control Kernel (SMACK). See http://www.schaufler-ca.com/ for details.
  4. Tomoyo that is a name based MAC and details can be found at http://sourceforge.jp/projects/tomoyo/docs.
  5. Yama extends the DAC support for ptrace. See Documentation/security/Yama.txt for further details.

The basic idea behind LSM is to:

  • Insert security function hooks and security data structures in the various kernel services to allow access control to be applied over and above that already implemented via DAC. The type of service that have hooks inserted are shown in Table 5 with an example task and program execution shown in the Fork Walk-thorough and Process Transition Walk-thorough sections.
  • Allow registration and initialisation services for the 3rd party security modules.
  • Allow process security attributes to be available to userspace services by extending the /proc filesystem with a security namespace as shown in Table 2. These are located at:
/proc/<self | pid>/attr/<attr>
/proc/<self | pid>/task/<tid>/attr/<attr>
Where <pid> is the process id, <tid> is the thread id and <attr> is the entry described in Table 2.
  • Support filesystems that use extended attributes (SELinux uses security.selinux as explained in the Labeling Extended Attribute Filesystems section).
  • Consolidate the Linux capabilities into an optional module.

It should be noted that the LSM does not provide any security services itself, only the hooks and structures for supporting 3rd party modules. If no 3rd party module is loaded, the capabilities module becomes the default module thus allowing standard DAC access control.

Table 1: LSM Hooks - These are the kernel services that LSM has inserted security hooks and structures to allow access control to be managed by 3rd party modules (see ./linux-3.14/include/linux/security.h).
Program execution Filesystem operations Inode operations
File operations Task operations Netlink messaging
Unix domain networking Socket operations XFRM operations
Key Management operations IPC operations Memory Segments
Semaphores Capability Sysctl
Syslog Audit


Table 2: /proc Filesystem attribute files - These files are used by the kernel services and libselinux (for userspace) to manage setting and reading of security contexts within the LSM defined data structures.
/proc/self/attr/ File Name
Permissions Function
current -rw-rw-rw- Contains the current process security context.
exec -rw-rw-rw- Used to set the security context for the next exec call.
fscreate -rw-rw-rw- Used to set the security context of a newly created file.
keycreate -rw-rw-rw- Used to set the security context for keys that are cached in the kernel.
prev -r--r--r-- Contains the previous process security context.
sockcreate -rw-rw-rw- Used to set the security context of a newly created socket.


The major kernel source files (relative to ./linux-3.14/security) that form the LSM are shown in Table 7. However there is one major header file (include/linux/security.h) that describes all the LSM security hooks and structures.

Table 3: The core LSM source modules.
Name Function
capability.c Some capability functions were in various kernel modules have been consolidated into these source files.
commoncap.c
device_cgroup.c
inode.c This allows the 3rd party security module to initialise a security filesystem. In the case of SELinux this would be /sys/fs/selinux that is defined in the selinux/selinuxfs.c source file.
security.c Contains the LSM framework initialisation services that will set up the hooks described in security.h and those in the capability source files. It also provides functions to initialise 3rd party modules.
lsm_audit.c Contains common LSM audit functions.
min_addr.c Minimum VM address protection from userspace for DAC and LSM.

The SELinux Module

This section does not go into detail of all the SELinux module functionality as the Implementing SELinux as a Linux Security Module does this (although a bit dated), however it attempts to highlight the way some areas work by using the fork and transition process example described in the Domain Transition section.

The major kernel SELinux source files (relative to ./linux-3.14/security/selinux) that form the SELinux security module are shown in Table 4. The diagrams shown inHigh Level SELinux Architecture and The Main LSM / SELinux Modules can be used to see how some of these kernel source modules fit together.

Table 4: The core SELinux source modules - The .h files and those in the include directory have a number of useful comments.
Name Function
avc.c Access Vector Cache functions and structures. The function calls are for the kernel services, however they have been ported to form the libselinux userspace library.
exports.c Exported SELinux services for SECMARK (as there is SELinux specific code in the netfilter source tree).
hooks.c Contains all the SELinux functions that are called by the kernel resources via the security_ops function table (they form the kernel resource object managers). There are also support functions for managing process exec's, managing SID allocation and removal, interfacing into the AVC and Security Server.
netif.c These manage the mapping between labels and SIDs for the net* language statements when they are declared in the active policy.
netnode.c
netport.c
netlabel.c The interface between NetLabel services and SELinux.
netlink.c Manages the notification of policy updates to resources including userspace applications via libselinux.
nlmsgtab.c
selinuxfs.c The selinuxfs pseudo filesystem (/sys/fs/selinux) that imports/exports security policy information to/from userspace services. The services exported are shown in the SELinux Filesystem section.
xfrm.c Contains the IPSec XFRM (transform) hooks for SELinux.
include/classmap.h classmap.h contains all the kernel security classes and permissions. initial_sid_to_string.h contains the initial SID contexts. These are used to build the flask.h and av_permissions.h kernel configuration files when the kernel is being built (using the genheaders script defined in the selinux/Makefile).

These files are built this way now to support the new dynamic security class mapping structure to remove the need for fixed class to SID mapping.

include/initial_sid_to_string.h
ss/avtab.c AVC table functions for inserting / deleting entries.
ss/conditional.c Support boolean statement functions and implements a conditional AV table to hold entries.
ss/ebitmap.c Bitmaps to represent sets of values, such as types, roles, categories, and classes.
ss/hashtab.c Hash table.
ss/mls.c Functions to support MLS.
ss/policydb.c Defines the structure of the policy database. See the "SELinux Policy Module Primer" article for details on the structure.
ss/services.c This contains the supporting services for kernel hooks defined in hooks.c, the AVC and the Security Server.

For example the security_transition_sid that computes the SID for a new subject / object shown in the The Main LSM / SELinux Modules diagram.

ss/sidtab.c The SID table contains the security context indexed by its SID value.
ss/status.c Interface for selinuxfs/status. Used by the libselinux selinux_status_*(3) functions.
ss/symtab.c Maintains associations between symbol strings and their values.


Fork System Call Walk-thorough

This section walks through the the fork(2) system call shown in the domain transition diagram starting at the kernel hooks that link to the SELinux services. The way the SELinux hooks are initialised into the LSM security_ops function table are also described.

Using the hooks for a fork diagram, the major steps to check whether the unconfined_t process has permission to use the fork permission are:

  1. The kernel/fork.c has a hook that links it to the LSM function security_task_create() that is called to check access permissions.
  2. Because the SELinux module has been initialised as the security module, the security_ops table has been set to point to the SELinux selinux_task_create() function in hooks.c.
  3. The selinux_task_create() function check whether the task has permission via the current_has_perm(current, PROCESS__FORK) function.
  4. This will result in a call to the AVC via the avc_has_perm() function in avc.c that checks whether the permission has been granted or not. First (via avc_has_perm_noaudit()) the cache is checked for an entry. Assuming that there is no entry in the AVC, then the security_compute_av() function in services.c is called.
  5. The security_compute_av() function will search the SID table for source and target entries, and if found will then call the context_struct_compute_av() function. The context_struct_compute_av() function carries out many checks to validate whether access is allowed. The steps are (assuming the access is valid):
    1. Initialise the AV structure so that it is clear.
    2. Check the object class and permissions are correct. It also checks the status of the allow_unknown flag (see the SELinux Filesystem, /etc/selinux/semanage.conf file and Reference Policy Build Options - build.conf UNK_PERMS sections).
    3. Checks if there are any type enforcement rules (ALLOW, AUDIT_ALLOW, AUDIT_DENY).
    4. Check whether any conditional statements are involved via the cond_compute_av() function in conditional.c.
    5. Remove permissions that are defined in any constraint via the constraint_expr_eval() function call (in services.c). This function will also check any MLS constraints.
    6. context_struct_compute_av() checks if a process transition is being requested (it is not). If it were, then the TRANSITION and DYNTRANSITION permissions are checked and whether the role is changing.
    7. Finally check whether there are any constraints applied via the typebounds rule.
  6. Once the result has been computed it is returned to the kernel/fork.c system call via the initial selinux_task_create() function. In this case the fork call is allowed.
  7. The End.


Process Transition Walk-thorough

This section walks through the execve(2) and checking whether a process transition to the ext_gateway_t domain is allowed, and if so obtain a new SID for the context (unconfined_u:message_filter_r:ext_gateway_t) as shown in the domain transition diagram.

The process starts with the Linux operating system issuing a do_execve[1] call from the CPU specific architecture code to execute a new program (for example, from <tt>arch/ia64/kernel/process.c). The do_execve() function is located in the fs/exec.c source code module and does the loading and final exec as described below.

do_execve() has a number of calls to security_bprm_* functions that are a part of the LSM (see include/linux/security.h), and are hooked by SELinux during the initialisation process (in security/selinux/hooks.c). Table 5 briefly describes these security_bprm functions that are hooks for validating program loading and execution (although see security.h for greater detail).

Table 5: The LSM / SELinux Program Loading Hooks
LSM / SElinux Function Name Description
security_bprm_set_creds->


selinux_bprm_set_creds
Set up security information in the bprm->security field based on the file to be exec'ed contained in bprm->file. SELinux uses this hook to check for domain transitions and the whether the appropriate permissions have been granted, and obtaining a new SID if required.
security_bprm_committing_creds->


selinux_bprm_committing_creds
Prepare to install the new security attributes of the process being transformed by an execve operation. SELinux uses this hook to close any unauthorised files, clear parent signal and reset resource limits if required.
security_bprm_committed_creds->


selinux_bprm_ committed_creds
Tidy up after the installation of the new security attributes of a process being transformed by an execve operation. SELinux uses this hook to check whether signal states can be inherited if new SID allocated.
security_bprm_secureexec->


selinux_bprm_secureexec
Called when loading libraries to check AT_SECURE flag for glibc secure mode support. SELinux uses this hook to check the process class noatsecure permission if appropriate.
security_bprm_check->


selinux_bprm_check_security
This hook is not used by SELinux.


Therefore starting at the do_execve() function and using the Process Transition diagram, the following major steps will be carried out to check whether the unconfined_t process has permission to transition the secure_server executable to the ext_gateway_t domain:

  1. The executable file is opened, a call issued to the sched_exec() function and the bprm structure is initialised with the file parameters (name, environment and arguments).
  2. Via the prepare_binprm() function call the UID and GIDs are checked and a call issued to security_bprm_set_creds() that will carry out the following:
  3. Call cap_bprm_set_creds function in commoncap.c, that will set up credentials based on any configured capabilities. If setexeccon(3) has been called prior to the exec, then that context will be used otherwise call security_transition_sid() function in services.c. This function will then call security_compute_sid() to check whether a new SID needs to be computed. This function will (assuming there are no errors):
    1. Search the SID table for the source and target SIDs.
    2. Sets the SELinux user identity.
    3. Set the source role and type.
    4. Checks that a type_transition rule exists in the AV table and / or the conditional AV table (see the The Main LSM / SELinux Modules diagram).
    5. If a type_transition, then also check for a role_transition (there is a role change in the ext_gateway.conf policy module), set the role.
    6. Check if any MLS attributes by calling mls_compute_sid() in mls.c. It also checks whether MLS is enabled or not, if so sets up MLS contexts.
    7. Check whether the contexts are valid by calling compute_sid_handle_invalid_context() that will also log an audit message if the context is invalid.
    8. Finally obtains a SID for the new context by calling sidtab_context_to_sid() in sidtab.c that will search the SID table (see the The Main LSM / SELinux Modules diagram) and insert a new entry if okay or log a kernel event if invalid.
  4. The selinux_bprm_set_creds() function will continue by checking via the avc_has_perm() functions (in avc.c) whether the file class file_execute_no_trans is set (in this case it is not), therefore the process class transition and file class file_entrypoint permissions are checked (in this case they are allowed), therefore the new SID is set, and after checking various other permissions, control is passed back to the do_execve function.
  5. The exec_binprm function will ultimately commit the credentials calling the SELinux selinux_bprm_committing_creds and selinux_bprm_committed_creds.
  6. Various strings are copied (args etc.) and a check is made to see if the exec succeeded or not (in this case it did), therefore the security_bprm_free() function is ultimately called to free the bprm security structure.
  7. The End.


SELinux Filesystem

Table 6 shows the information contained in the SELinux filesystem (selinuxfs) /sys/fs/selinux (or /selinux on older systems) where the SELinux kernel exports information regarding its configuration and active policy. selinuxfs is a read/write interface used by SELinux library functions for userspace SELinux-aware applications and object managers. Note: while it is possible for userspace applications to read/write to this interface, it is not recommended - use the libselinux library.

Table 6: selinux filesystem Information
selinuxfs Directory and File Names
Permissions
Comments
/sys/fs/selinux
Directory
This is the root directory where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the libselinux library.
access
-rw-rw-rw-
Compute access decision interface that is used by the security_compute_av(3), security_compute_av_flags(3), avc_has_perm(3)and avc_has_perm_noaudit(3) functions.

The kernel security server (see services.c) converts the contexts to SIDs and then calls the security_compute_av_user function to compute the new SID that is then converted to a context string.

Requires security {compute_av} permission.

checkreqprot
-rw-r--r--
0 = Check requested protection applied by kernel.

1 = Check protection requested by application. This is the default.

These apply to the mmap and mprotect kernel calls. Default value can be changed at boot time via the checkreqprot= parameter.

Requires security {setcheckreqprot} permission.

commit_pending_bools
--w-------
Commit new boolean values to the kernel policy.

Requires security {setbool} permission.

context
-rw-rw-rw-
Validate context interface used by the security_check_context(3) function.

Requires security {check_context} permission.

create
-rw-rw-rw-
Compute create labeling decision interface that is used by the security_compute_create(3) and avc_compute_create(3) functions.

The kernel security server (see services.c) converts the contexts to SIDs and then calls the security_transition_sid_user function to compute the new SID that is then converted to a context string.

Requires security {compute_create} permission.

deny_unknown
-r--r--r--
These two files export deny_unknown (read by security_deny_unknown(3) function) and reject_unknown status to user space.

These are taken from the handle-unknown parameter set[2] in the /etc/selinux/semanage.conf file when policy is being built and are set as follows:

deny:reject

0:0 = Allow unknown object class / permissions. This will set the returned AV with all 1's.

1:0 = Deny unknown object class / permissions (the default). This will set the returned AV with all 0's.

1:1 = Reject loading the policy if it does not contain all the object classes / permissions.

reject_unknown
-r--r--r--
disable
--w-------
Disable SELinux until next reboot.
enforce
-rw-r--r--
Get or set enforcing status.

Requires security {setenforce} permission.

load
-rw-------
Load policy interface.

Requires security {load_policy} permission.

member
-rw-rw-rw-
Compute polyinstantiation membership decision interface that is used by the security_compute_member(3) and avc_compute_member(3) functions.

The kernel security server (see services.c) converts the contexts to SIDs and then calls the security_member_sid function to compute the new SID that is then converted to a context string.

Requires security {compute_member} permission.

mls
-r--r--r--
Returns 1 if MLS policy is enabled or 0 if not.
null
crw-rw-rw-
The SELinux equivalent of /dev/null for file descriptors that have been redirected by SELinux.
policy
-r--r--r--
Interface to upload the current running policy in kernel binary format. This is useful to check the running policy using apol(1) , dispol/sedispol etc. (e.g. cat /sys/fs/selinux/policy > current-policy then load it into the required tool).
policyvers
-r--r--r--
Returns supported policy version for kernel. Read by security_policyvers(3) function.
relabel
-rw-rw-rw-
Compute relabeling decision interface that is used by the security_compute_relabel(3) function.

The kernel security server (see services.c) converts the contexts to SIDs and then calls the security_change_sid function to compute the new SID that is then converted to a context string.

Requires security {compute_relabel} permission.

status
-r--r--r--
This can be used to obtain enforcing mode and policy load changes with much less over-head than using the libselinux netlink / call backs. This was added for Object Managers that have high volumes of AVC requests so they can quickly check whether to invalidate their cache or not.

The status structure indicates the following:

version - Version number of the status structure. This will increase as other entries are added.

sequence - This is incremented for each event with an even number meaning that the events are stable. An odd number indicates that one of the events is changing and therefore the userspace application should wait before reading the status of any event.

enforcing - 0 = Permissive mode, 1 = enforcing mode.

policyload - This contains the policy load sequence number and should be read and stored, then compared to detect a policy reload.

deny_unknown - 0 = Allow and 1 = Deny unknown object classes / permissions. This is the same as the deny_unknown entry above.

user
-rw-rw-rw-
Compute reachable user contexts interface that is used by the security_compute_user(3) function.

The kernel security server (see services.c) converts the contexts to SIDs and then calls the security_get_user_sids function to compute the user SIDs that are then converted to context strings.

Requires security {compute_user} permission.

/sys/fs/selinux/avc
Directory
This directory contains information regarding the kernel AVC that can be displayed by the avcstat command.
cache_stats
-r--r--r--
Shows the kernel AVC lookups, hits, misses etc.
cache_threshold
-rw-r--r--
The default value is 512, however caching can be turned off (but performance suffers) by:
echo 0 > /selinux/avc/cache_threshold

Requires security {setsecparam} permission.

hash_stats
-r--r--r--
Shows the number of kernel AVC entries, longest chain etc.
/sys/fs/selinux/booleans
Directory
This directory contains one file for each boolean defined in the active policy.
secmark_audit
......
......
-rw-r--r--
Each file contains the current and pending status of the boolean (0 = false or 1 = true). The getsebool(8), setsebool(8) and sestatus(8) -b commands use this interface via the libselinux library functions.
/sys/fs/selinux/initial_contexts
Directory
This directory contains one file for each initial SID defined in the active policy. The file name is the initial SID name with the contents containing its security context.
any_socket
devnull
.....
-r--r--r--
Each file contains the initial context of the initial SID as defined in the active policy (e.g. any_socket was assigned system_u:object_r:unconfined_t).
/sys/fs/selinux/policy_capabilities
Directory
This directory contains the policy capabilities that have been configured by default in the kernel via the policycap statement in the active policy. These are generally new features that can be enabled by using the policycap statement in policy. Their default values are false.
always_check_network
-r--r--r--
If true SECMARK and peer labeling are always enabled even if there are no SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of the packet class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.14 minimum.
network_peer_controls
-r--r--r--
If true the following network_peer_controls are enabled:

node: sendto recvfrom

netif: ingress egress

peer: recv

open_perms
-r--r--r--
If true the open permissions are enabled by default on the following object classes: dir, file, fifo_file, chr_file, blk_file.
redhat1
-r--r--r--
Available in kernel 3.4 to allow finer control of ptrace (this will be named correctly one day). Requires policy support and the security class permission ptrace_child.
/sys/fs/selinux/class
Directory
This directory contains a list of classes and their permissions as defined by the policy (for the Reference Policy the order in the security_classes and access_vectors files).
/sys/fs/selinux/class/appletalk_socket
Directory
Each class has its own directory where each one is named using the appropriate class statement from the policy (i.e. class appletalk_socket). Each directory contains the following:
index
-r--r--r--
This file contains the allocated class number (e.g. appletalk_socket is the 56th entry in the policy security_classes file).
/sys/fs/selinux/class/appletalk_socket/perms
Directory
This directory contains one file for each permission defined in the policy.
accept
append
bind
....
-r--r--r--
Each file is named by the permission assigned in the policy and contains a number that represents its position in the list (e.g. accept is the 14th permission listed in the policy access_vector file for the appletalk_socket and therefore contains '14'.


Notes:

  1. Kernel SIDs are not passed to userspace only the context strings.
  2. The /proc filesystem exports the process security context string to userspace via /proc/<self|pid>/attr and /proc/<self|pid>/task/<tid>/attr/<attr> interfaces.


Previous
Home
Next



  1. This function call will pass over the file name to be run and its environment + arguments.
  2. This is also set in the UNK_PERMS entry of the Reference Policy [#_Reference_Policy_Build_Options (bui build.conf] file. The entry in semanage.conf will over-ride the build.conf entry.