Signed-off-by: Richard Haines <richard_c_haines@xxxxxxxxxxxxxx> --- src/security_context.md | 83 ++++++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 38 deletions(-) diff --git a/src/security_context.md b/src/security_context.md index 3ca93a2..cb0fc4a 100644 --- a/src/security_context.md +++ b/src/security_context.md @@ -20,47 +20,50 @@ user:role:type[:range] **Where:** -<table> -<tbody> -<tr> -<td><code>user</code></td> -<td>The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.</td> -</tr> -<tr> -<td><code>role</code></td> -<td>The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.</td> -</tr> -<tr> -<td><code>type</code></td> -<td><p>When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.</p> -<p>When a type is associated with an object, it defines what access permissions the SELinux user has to that object.</p></td> -</tr> -<tr> -<td><code>range</code></td> -<td><p>This field can also be know as a <em>level</em> and is only present if the policy supports MCS or MLS. The entry can consist of: -<p>A single security level that contains a sensitivity level and zero or more categories (e.g. s0, s1:c0, s7:c10.c15).</p> -<p>A range that consists of two security levels (a low and high) separated by a hyphen (e.g. s0 - s15:c0.c1023).</p> -<p>These components are discussed in the <a href="mls_mcs.md#security-levels">Security Levels</a> section.</p></td> -</tr> -</tbody> -</table> +*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**]( mls_mcs.md#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 constraints 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 constraints on the role within policy - based on their object class. +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*[^fn_sc_1] + or it is set to the SELinux user id of the creating process. It is + possible to add constraints 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 constraints on the role within policy + based on their object class. The [**Computing Security Contexts**](computing_security_contexts.md#computing-security-contexts) section decribes how SELinux computes the security context components based @@ -116,6 +119,10 @@ unconfined_u:object_r:out_file_t Message-11 # (see the process example above). The role remained as object_r. ``` +[^fn_sc_1]: The user *system_u* name is not mandatory, it is used to signify +a special user in the Reference Policy. It is also used in some SELinux +utilities. + <!-- %CUTHERE% --> --- -- 2.26.2
