BasicConcepts - Revision history

JoshuaBrindle: /* Rules */

JoshuaBrindle — Thu, 19 Nov 2009 18:35:31 GMT

Rules

←Older revision		Revision as of 18:35, 19 November 2009
Line 33:		Line 33:
	allow user_t user_home_t:file { create read write unlink };		allow user_t user_home_t:file { create read write unlink };

-	This rule states that the ''user_t'' type is allowed to create, read, write, and delete files with the user_home_t type. More information on adding rules to the policy will be covered in other pages.	+	This rule states that the ''user_t'' type is allowed to create, read, write, and delete files with the ''user_home_t'' type. More information on adding rules to the policy will be covered in other pages.

JoshuaBrindle: /* Contexts */

JoshuaBrindle — Thu, 19 Nov 2009 18:34:35 GMT

Contexts

←Older revision		Revision as of 18:34, 19 November 2009
Line 9:		Line 9:

	= Contexts =		= Contexts =
-	Every process and object in the system has a context (also known as a label). This is an attribute used to determine if an access should be allowed between a process and an object. For example, a user process might have the context of user_u:user_r:user_t, and file in the user's home directory might have the context user_u:object_r:user_home_t. A SELinux context consists of three required fields, and one optional field:	+	Every process and object in the system has a context (also known as a label). This is an attribute used to determine if an access should be allowed between a process and an object. For example, a user process might have the context of ''user_u:user_r:user_t'', and file in the user's home directory might have the context ''user_u:object_r:user_home_t''. A SELinux context consists of three required fields, and one optional field:

	user:role:type:range		user:role:type:range
Line 17:		Line 17:
	system_u:system_r:xserver_t		system_u:system_r:xserver_t

-	In this context, the user is system_u, the role is system_r, and the type is xserver_t. The following is an example context, with the MLS field:	+	In this context, the user is ''system_u'', the role is ''system_r'', and the type is ''xserver_t''. The following is an example context, with the MLS field:

	system_u:system_r:xserver_t:s0-s0:c0.c1023		system_u:system_r:xserver_t:s0-s0:c0.c1023

ChrisPeBenito: /* Contexts */

ChrisPeBenito — Wed, 04 Nov 2009 15:21:55 GMT

Contexts

←Older revision		Revision as of 15:21, 4 November 2009
Line 19:		Line 19:
	In this context, the user is system_u, the role is system_r, and the type is xserver_t. The following is an example context, with the MLS field:		In this context, the user is system_u, the role is system_r, and the type is xserver_t. The following is an example context, with the MLS field:

-	system_u:system_r:xserver_t:s0-s0:c0.~~c255~~	+	system_u:system_r:xserver_t:s0-s0:c0.c1023
		+
		+	If MLS translations are enabled, the above context might instead be:
		+
		+	system_u:system_r:xserver_t:SystemLow-SystemHigh

	= Object Classes =		= Object Classes =

ChrisPeBenito at 15:32, 3 November 2009

ChrisPeBenito — Tue, 03 Nov 2009 15:32:42 GMT

←Older revision		Revision as of 15:32, 3 November 2009
Line 13:		Line 13:
	user:role:type:range		user:role:type:range

-	The first field is the SELinux user. The second field is the role. The third field in the type. The forth field is the MLS range; this field is optional, and will be discussed later.	+	The first field is the SELinux user. The second field is the role. The third field in the type. The forth field is the MLS range; this field is optional, and will be discussed later. The following is an example context:
		+
		+	system_u:system_r:xserver_t
		+
		+	In this context, the user is system_u, the role is system_r, and the type is xserver_t. The following is an example context, with the MLS field:
		+
		+	system_u:system_r:xserver_t:s0-s0:c0.c255

	= Object Classes =		= Object Classes =

ChrisPeBenito at 15:46, 29 October 2009

ChrisPeBenito — Thu, 29 Oct 2009 15:46:08 GMT

←Older revision		Revision as of 15:46, 29 October 2009
Line 1:		Line 1:
-	= ~~SELinux Context~~ =	+	= Users =
-	~~Every process and object in the system has a context (alternatively referred~~ to as a ~~label)~~. ~~This is an attribute used to determine if an access should be allowed~~ between ~~a process~~ and ~~an object. For example~~, a user ~~process~~ might ~~have~~ the ~~context of user_u:user_r~~:~~user_t~~, ~~and file in~~ the user~~'s home directory might have~~ the ~~context user_u:object_r:user_home_t~~. A SELinux ~~context consists of three required fields~~, ~~and one optional field~~.	+	The SELinux user is not equivalent to a Linux user. One significant difference between the SELinux users and Linux users is SELinux users do not change during a user session, whereas a Linux user might change via su or sudo. Typically many Linux users will use the same SELinux user, but it is possible to have a 1:1 Linux user to SELinux user mapping, such as the root Linux user and the root SELinux user. By convention, SELinux users that are generic have the suffix "_u", such as ''user_u''.

-	~~The first field is the~~ SELinux user. ~~The SELinux user~~ is ~~not equivalent to a Linux user. Typically many Linux users will use~~ the ~~same SELinux user~~, but ~~it is possible to have a 1:1 Linux~~ user ~~to SELinux user mapping~~, ~~such as the root Linux user and the root SELinux user. One significant difference between the SELinux users and Linux users is SELinux users do not change during~~ a ~~user session~~, ~~whereas~~ a ~~Linux user might change via su or sudo~~. By convention, ~~SELinux users that are generic~~ have the suffix "_u", such as ''~~user_u~~''.	+	= Roles =
		+	A SELinux user may be allowed to take on one or more roles. What a role means is defined by the policy, but examples of roles are an unprivileged user, a web administrator, and a database administrator. Objects typically have the role ''object_r''. By convention, roles have the suffix "_r", such as ''user_r''.

-	~~The second field~~ is the ~~role. A SELinux user may~~ be ~~allowed to take on one or more roles~~. ~~What~~ a ~~role means~~ is ~~defined by the policy, but examples of roles are an unprivileged user, a web administrator, and a database administrator. Objects typically have the role ''object_r''~~. By convention, ~~roles have~~ the suffix "_r".	+	= Types =
		+	This is the primary means of determining access (this will be further discussed later). The type of a process is also referred to as its domain. By convention, a type has the suffix "_t", such as ''user_t''.

-	~~The third field~~ in the ~~type~~. This is ~~the primary means of determining~~ access ~~(this will~~ be ~~further discussed later). The type of~~ a process ~~is also referred to as its domain~~. ~~By convention~~, a ~~type has~~ the ~~suffix "_t"~~, ~~such as ''user_t'~~'.	+	= Contexts =
		+	Every process and object in the system has a context (also known as a label). This is an attribute used to determine if an access should be allowed between a process and an object. For example, a user process might have the context of user_u:user_r:user_t, and file in the user's home directory might have the context user_u:object_r:user_home_t. A SELinux context consists of three required fields, and one optional field:

-	The forth field is the MLS range~~. This~~ field optional, and will be discussed later.	+	user:role:type:range
		+
		+	The first field is the SELinux user. The second field is the role. The third field in the type. The forth field is the MLS range; this field is optional, and will be discussed later.

	= Object Classes =		= Object Classes =
	SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''. See [[ObjectClassesPerms]] for a complete listing of object classes and their permissions.		SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''. See [[ObjectClassesPerms]] for a complete listing of object classes and their permissions.
		+
		+	= Rules =
		+	The primary security mechanism of SELinux is type enforcement, meaning that rules are specified using the type of the process and object:
		+
		+	allow user_t user_home_t:file { create read write unlink };
		+
		+	This rule states that the ''user_t'' type is allowed to create, read, write, and delete files with the user_home_t type. More information on adding rules to the policy will be covered in other pages.

ChrisPeBenito at 15:21, 29 October 2009

ChrisPeBenito — Thu, 29 Oct 2009 15:21:27 GMT

←Older revision		Revision as of 15:21, 29 October 2009
Line 11:		Line 11:

	= Object Classes =		= Object Classes =
-	SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''.	+	SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''. See [[ObjectClassesPerms]] for a complete listing of object classes and their permissions.

ChrisPeBenito at 15:20, 29 October 2009

ChrisPeBenito — Thu, 29 Oct 2009 15:20:01 GMT

←Older revision		Revision as of 15:20, 29 October 2009
Line 8:		Line 8:
	The third field in the type. This is the primary means of determining access (this will be further discussed later). The type of a process is also referred to as its domain. By convention, a type has the suffix "_t", such as ''user_t''.		The third field in the type. This is the primary means of determining access (this will be further discussed later). The type of a process is also referred to as its domain. By convention, a type has the suffix "_t", such as ''user_t''.

-	The forth field is the MLS range. This field will be discussed later.	+	The forth field is the MLS range. This field optional, and will be discussed later.

	= Object Classes =		= Object Classes =
	SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''.		SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''.

ChrisPeBenito: New page: = SELinux Context = Every process and object in the system has a context (alternatively referred to as a label). This is an attribute used to determine if an access should be allowed betw...

ChrisPeBenito — Thu, 29 Oct 2009 15:19:34 GMT

New page: = SELinux Context = Every process and object in the system has a context (alternatively referred to as a label). This is an attribute used to determine if an access should be allowed betw...

New page

= SELinux Context =
Every process and object in the system has a context (alternatively referred to as a label). This is an attribute used to determine if an access should be allowed between a process and an object. For example, a user process might have the context of user_u:user_r:user_t, and file in the user's home directory might have the context user_u:object_r:user_home_t. A SELinux context consists of three required fields, and one optional field.

The first field is the SELinux user. The SELinux user is not equivalent to a Linux user. Typically many Linux users will use the same SELinux user, but it is possible to have a 1:1 Linux user to SELinux user mapping, such as the root Linux user and the root SELinux user. One significant difference between the SELinux users and Linux users is SELinux users do not change during a user session, whereas a Linux user might change via su or sudo. By convention, SELinux users that are generic have the suffix "_u", such as ''user_u''.

The second field is the role. A SELinux user may be allowed to take on one or more roles. What a role means is defined by the policy, but examples of roles are an unprivileged user, a web administrator, and a database administrator. Objects typically have the role ''object_r''. By convention, roles have the suffix "_r".

The third field in the type. This is the primary means of determining access (this will be further discussed later). The type of a process is also referred to as its domain. By convention, a type has the suffix "_t", such as ''user_t''.

The forth field is the MLS range. This field will be discussed later.

= Object Classes =
SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the ''file'' object class has the permissions ''create'', ''read'', ''write'', and ''unlink'' (delete), while the ''unix_stream_socket'' object class (UNIX domain stream sockets) has the permissions ''create'', ''connect'', and ''sendto''.