From SELinux Wiki
|Revision as of 20:25, 31 August 2010 (edit)
Jaxelson (Talk | contribs)
← Previous diff
|Revision as of 21:05, 13 September 2010 (edit) (undo)
Jaxelson (Talk | contribs)
Next diff →
|Line 32:||Line 32:|
Revision as of 21:05, 13 September 2010
See Also: TypeEnforcement
Type Enforcement (TE)
SELinux makes use of a specific style of type enforcement (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 of volume 2, 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).
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 various "type enforcement" technologies.