NB TE - Revision history

Jaxelson: /* Type Enforcement (TE) */ linked mandatory access control

Jaxelson — Mon, 13 Sep 2010 23:21:41 GMT

Type Enforcement (TE) - linked mandatory access control

←Older revision		Revision as of 23:21, 13 September 2010
Line 1:		Line 1:
	''See Also: [[TypeEnforcement]]''		''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.

Jaxelson: linked building a basic policy

Jaxelson — Mon, 13 Sep 2010 21:21:44 GMT

linked building a basic policy

←Older revision		Revision as of 21:21, 13 September 2010
Line 9:		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).

Jaxelson: /* Type Enforcement (TE) */ linked reference policy

Jaxelson — Mon, 13 Sep 2010 21:20:06 GMT

Type Enforcement (TE) - linked reference policy

←Older revision		Revision as of 21:20, 13 September 2010
Line 11:		Line 11:
	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 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).

-	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 ==

Jaxelson at 21:05, 13 September 2010

Jaxelson — Mon, 13 Sep 2010 21:05:25 GMT

←Older revision		Revision as of 21:05, 13 September 2010
Line 32:		Line 32:
	----		----
	<references/>		<references/>
		+
		+	[[Category:Notebook]]

Jaxelson at 20:25, 31 August 2010

Jaxelson — Tue, 31 Aug 2010 20:25:53 GMT

←Older revision		Revision as of 20:25, 31 August 2010
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.

RichardHaines: /* Constraints */

RichardHaines — Fri, 21 May 2010 15:21:21 GMT

Constraints

←Older revision		Revision as of 15:21, 21 May 2010
Line 25:		Line 25:
	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).

RichardHaines: New page: = Type Enforcement (TE) = SELinux makes use of a specific style of type enforcement^{There are various "type enforcement" technologies.} (TE) to enforce man...

RichardHaines — Sun, 16 May 2010 13:54:35 GMT

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...

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 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.

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 "<tt>_t</tt>"). 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 <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).

== Constraints ==
Within a TE environment the way that subjects are allowed to access an object is via an <tt>allow</tt> rule, for example:
<pre>
allow unconfined_t ext_gateway_t : process transition;
</pre>

This is explained in more detail later, however it states that a process running in the <tt>unconfined_t</tt> domain has permission to transition a process to the <tt>ext_gateway_t</tt> 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 <tt>constrain</tt> statement:
<pre>
constrain process transition ( r1 == r2 );
</pre>

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).

----
<references/>