NB TE

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:54, 16 May 2010 (edit)
RichardHaines (Talk | contribs)
(New page: = Type Enforcement (TE) = SELinux makes use of a specific style of type enforcement<ref name="ftn5"><sup>There are various "type enforcement" technologies. </sup></ref> (TE) to enforce man...)
← Previous diff
Revision as of 23:21, 13 September 2010 (edit) (undo)
Jaxelson (Talk | contribs)
(Type Enforcement (TE) - linked mandatory access control)
Next diff →
(5 intermediate revisions not shown.)
Line 1: Line 1:
 +''See Also: [[TypeEnforcement]]''
= Type Enforcement (TE) = = Type Enforcement (TE) =
-SELinux makes use of a specific style of type enforcement<ref name="ftn5"><sup>There are various "type enforcement" technologies. </sup></ref> (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy. +SELinux makes use of a specific style of type enforcement<ref name="ftn5"><sup>There are various "type enforcement" technologies. </sup></ref> (TE) to enforce [[mandatory access control]]. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down in a policy.
The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy. The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce the policy.
Line 8: Line 9:
Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type). Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).
-While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the Building a Basic Policy section of volume 2, all the processes on the system run in the unconfined_t domain, therefore every process is "of type <tt>unconfined_t</tt>" (that means it can do whatever it likes within the limits of the standard Linux DAC policy).+While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the [[Building a Basic Policy]] section, all the processes on the system run in the unconfined_t domain, therefore every process is "of type <tt>unconfined_t</tt>" (that means it can do whatever it likes within the limits of the standard Linux DAC policy).
-It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (<tt>ext_gateway_t</tt>) that cannot be "interfered" with by any of the <tt>unconfined_t</tt> processes (except to run or transition the gateway process into its own domain). This scenario is similar to the "targeted" policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the Reference Policy have areas isolated by various domains and has evolved over years of work).+It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (<tt>ext_gateway_t</tt>) that cannot be "interfered" with by any of the <tt>unconfined_t</tt> processes (except to run or transition the gateway process into its own domain). This scenario is similar to the "targeted" policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the [[Reference Policy]] have areas isolated by various domains and has evolved over years of work).
== Constraints == == Constraints ==
Line 25: Line 26:
This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section. This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the [[ConstraintStatements | Constraint Statements]] section.
-There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLS_Statements | MLS Statements]] sections). +There are a number of different constraint statements within the policy language to support areas such as MLS (see the [[ConstraintStatements | Constraint Statements]] and [[MLSStatements | MLS Statements]] sections).
Line 31: Line 32:
---- ----
<references/> <references/>
 +
 +[[Category:Notebook]]

Revision as of 23:21, 13 September 2010

See Also: TypeEnforcement

Type Enforcement (TE)

SELinux makes use of a specific style of type enforcement[1] (TE) to enforce mandatory access control. For SELinux it means that all subjects and objects have a type identifier associated to them that can then be used to enforce rules laid down in a policy.

The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a security context. It is also used in the majority of SELinux language statements and rules used to build a policy that will, when loaded into the security server, enforce the policy.

Because the type identifier (or just "type") is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers all end in "_t"). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services.

Basically if the type identifier is used to reference a subject it is referring to a GNU / Linux process or domain (i.e. domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).

While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the Building a Basic Policy section, all the processes on the system run in the unconfined_t domain, therefore every process is "of type unconfined_t" (that means it can do whatever it likes within the limits of the standard Linux DAC policy).

It is only when additional policies are implemented in the simple policy (via loadable modules), that areas start to be confined, for example an external gateway is run in its own isolated domain (ext_gateway_t) that cannot be "interfered" with by any of the unconfined_t processes (except to run or transition the gateway process into its own domain). This scenario is similar to the "targeted" policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think they are equivalent as the policies supplied with the Reference Policy have areas isolated by various domains and has evolved over years of work).

Constraints

Within a TE environment the way that subjects are allowed to access an object is via an allow rule, for example:

allow unconfined_t ext_gateway_t : process transition;

This is explained in more detail later, however it states that a process running in the unconfined_t domain has permission to transition a process to the ext_gateway_t domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a constrain statement:

constrain process transition ( r1 == r2 );

This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). An example of this can be found in the Constraint Statements section.

There are a number of different constraint statements within the policy language to support areas such as MLS (see the Constraint Statements and MLS Statements sections).



  1. There are various "type enforcement" technologies.
Personal tools