Difference between revisions of "NB SC"

From SELinux Wiki
Jump to: navigation, search
(Security Context)
Line 1: Line 1:
 
= Security Context =
 
= Security Context =
SELinux requires a security context to be associated with every process (or [[SELinux subject|subject]]) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.
+
SELinux requires a security context to be associated with every process (or subject) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.
  
The security context is also known as a "security label" or just label that can cause confusion as there are many types of label depending on the context (another context!!).
+
The security context is also known as a 'security label' or just label that can cause confusion as there are many types of label depending on the context (another context!!).
  
Within SELinux, a security context is represented as variable-length strings that define the SELinux user<ref name="ftn7"><sup>An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files (via the <tt>semanage(8)</tt> command).</sup></ref>, their role, a type identifier and an optional MCS / MLS security level as follows:
+
Within SELinux, a security context is represented as variable-length strings that define the SELinux user<ref name="ftn3"><sup>An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files.</sup></ref>, their role, a type identifier and an optional MCS / MLS security range or level as follows:
 
<pre>
 
<pre>
user:role:type[:level]
+
user:role:type[:range]
 
</pre>
 
</pre>
  
Line 25: Line 25:
  
 
|-
 
|-
| <tt>level</tt>
+
| <tt>range</tt>
| This optional field can also be know as a <tt>range</tt> and is only present if the policy supports MCS or MLS. The entry can consist of:
+
| This field can also be know as a <tt>level</tt> and is only present if the policy supports MCS or MLS. The entry can consist of:
  
 
* A single security <tt>level</tt> that contains a sensitivity level and zero or more categories (e.g. <tt>s0</tt>, <tt>s1:c0</tt>, <tt>s7:c10.c15</tt>).
 
* A single security <tt>level</tt> that contains a sensitivity level and zero or more categories (e.g. <tt>s0</tt>, <tt>s1:c0</tt>, <tt>s7:c10.c15</tt>).
Line 37: Line 37:
  
 
However note that:
 
However note that:
# Access decisions regarding a subject make use of all the components of the [[NB_SC | security context]].
 
# Access decisions regarding an object make use of all the components of the security context, however:
 
:: a) the user is either set to a special user called <tt>system_u</tt> or it is set to the SELinux user id of the creating process (as it serves no real purpose other than it can be used for audit purposes within logs).
 
:: b) the role is not relevant to security decisions and is always set to a special SELinux internal role of <tt>object_r</tt>.
 
  
Therefore for an object, the type (and level for MLS) are the only relevant security fields that are used in access decisions.  
+
# Access decisions regarding a subject make use of all the components of the security context.
 +
# Access decisions regarding an object make use of the components as follows:
 +
## the user is either set to a special user called system_u or it is set to the SELinux user id of the creating process. It is possible to add contraints on users within policy based on their object class (an example of this is the Reference Policy UBAC (User Based Access Control) option.
 +
## the role is generally set to a special SELinux internal role of <tt>object_r</tt>, although policy version 26 with kernel 2.6.39 and above do support role transitions on any object class. It is then possible to add contraints on the role within policy based on their object class.
  
Examples of using <tt>system_u</tt> and <tt>object_r</tt> can be seen in the file system after relabeling and running the <tt>ls -Z</tt> command on various directories.
+
The [[NB_ComputingSecurityContexts | Computing Security Contexts]] section decribes how SELinux computes the security context components based on a source context, target context and object class.
  
The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no <tt>level</tt> field):
+
The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no level field):
  
 
'''Example Process Security Context:'''
 
'''Example Process Security Context:'''
Line 53: Line 52:
 
# (edited for clarity) that show four processes:
 
# (edited for clarity) that show four processes:
  
LABEL                                 PID  TTY  CMD
+
LABEL                                       PID  TTY  CMD
user_u:unconfined_r:unconfined_t      2539 pts/0 bash
+
unconfined_u:unconfined_r:unconfined_t      2539 pts/0 bash
user_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server
+
unconfined_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server
user_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server
+
unconfined_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server
user_u:unconfined_r:unconfined_t     3146 pts/0 ps
+
unconfined_u:unconfined_r:unconfined_t 3146 pts/0 ps
  
 
# Note the bash and ps processes are running under the  
 
# Note the bash and ps processes are running under the  
Line 74: Line 73:
 
# taken from an ls -Zd command (edited for clarity):
 
# taken from an ls -Zd command (edited for clarity):
  
system_u:object_r:in_queue_t /user/message_queue/in_queue
+
system_u:object_r:in_queue_t /usr/message_queue/in_queue
system_u:object_r:out_queue_t /user/message_queue/out_queue
+
system_u:object_r:out_queue_t /usr/message_queue/out_queue
  
 
# Note that they are instantiated with system_u and object_r
 
# Note that they are instantiated with system_u and object_r
Line 84: Line 83:
 
# taken from an ls -Z command (edited for clarity):
 
# taken from an ls -Z command (edited for clarity):
  
/user/message_queue/in_queue:
+
/usr/message_queue/in_queue:
user_u:object_r:in_file_t Message-1
+
unconfined_u:object_r:in_file_t Message-1
user_u:object_r:in_file_t Message-2
+
unconfined_u:object_r:in_file_t Message-2
  
/user/message_queue/out_queue:
+
/usr/message_queue/out_queue:
user_u:object_r:out_file_t Message-10
+
unconfined_u:object_r:out_file_t Message-10
user_u:object_r:out_file_t Message-11
+
unconfined_u:object_r:out_file_t Message-11
  
# Note that they are instantiated with user_u as that was the
+
# Note that they are instantiated with unconfined_u as that was
# SELinux user id of the process that created the files (see the
+
# the SELinux user id of the process that created the files  
# process example above). The role remained as object_r.
+
# (see the process example above). The role remained as object_r.
 
</pre>
 
</pre>
 +
  
 
----
 
----
 
<references/>
 
<references/>
 +
 
[[Category:Notebook]]
 
[[Category:Notebook]]

Revision as of 13:10, 5 December 2014

Security Context

SELinux requires a security context to be associated with every process (or subject) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.

The security context is also known as a 'security label' or just label that can cause confusion as there are many types of label depending on the context (another context!!).

Within SELinux, a security context is represented as variable-length strings that define the SELinux user[1], their role, a type identifier and an optional MCS / MLS security range or level as follows:

user:role:type[:range]

Where:

user The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.
role The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.
type When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.

When a type is associated with an object, it defines what access permissions the SELinux user has to that object.

range This field can also be know as a level and is only present if the policy supports MCS or MLS. The entry can consist of:
  • A single security level that contains a sensitivity level and zero or more categories (e.g. s0, s1:c0, s7:c10.c15).
  • A range that consists of two security levels (a low and high) separated by a hyphen (e.g. s0 - s15:c0.c1023).

These components are discussed in the Security Levels section.


However note that:

  1. Access decisions regarding a subject make use of all the components of the security context.
  2. Access decisions regarding an object make use of the components as follows:
    1. the user is either set to a special user called system_u or it is set to the SELinux user id of the creating process. It is possible to add contraints on users within policy based on their object class (an example of this is the Reference Policy UBAC (User Based Access Control) option.
    2. the role is generally set to a special SELinux internal role of object_r, although policy version 26 with kernel 2.6.39 and above do support role transitions on any object class. It is then possible to add contraints on the role within policy based on their object class.

The Computing Security Contexts section decribes how SELinux computes the security context components based on a source context, target context and object class.

The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no level field):

Example Process Security Context:

# These are process security contexts taken from a ps -Z command 
# (edited for clarity) that show four processes:

LABEL                                       PID  TTY   CMD
unconfined_u:unconfined_r:unconfined_t      2539 pts/0 bash
unconfined_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server
unconfined_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server
unconfined_u:unconfined_r:unconfined_t 3146 pts/0 ps

# Note the bash and ps processes are running under the 
# unconfined_t domain, however the secure_server has two instances
# running under two different domains (ext_gateway_t and 
# int_gateway_t). Also note that they are using the 
# message_filter_r role whereas bash and ps use unconfined_r.
#
# These results were obtained by running the system in permissive
# mode (as in enforcing mode the gateway processes would not be shown).

Example Object Security Context:

# These are the message queue directory object security contexts 
# taken from an ls -Zd command (edited for clarity):

system_u:object_r:in_queue_t /usr/message_queue/in_queue
system_u:object_r:out_queue_t /usr/message_queue/out_queue

# Note that they are instantiated with system_u and object_r
# These are the message queue file object security contexts 
# taken from an ls -Z command (edited for clarity):

/usr/message_queue/in_queue:
unconfined_u:object_r:in_file_t Message-1
unconfined_u:object_r:in_file_t Message-2

/usr/message_queue/out_queue:
unconfined_u:object_r:out_file_t Message-10
unconfined_u:object_r:out_file_t Message-11

# Note that they are instantiated with unconfined_u as that was
# the SELinux user id of the process that created the files 
# (see the process example above). The role remained as object_r.



  1. An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files.