Security context

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (Expanded acronyms)
m (Grammar: 'a extended file' > 'an extended file')
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Security Context =
+
[[Image:SELinux-context.png|thumb|right|300px|The SELinux security context of [http://linux.die.net/man/1/passwd <code>passwd(1)</code>], as shown by the command: <code>ls -Z /usr/bin/passwd</code>]]
  
 +
A '''security context''', or '''security label''', is the mechanism used by [[SELinux]] to classify resources, such as processes and files, on a SELinux-enabled system. This context allows SELinux to enforce rules for how and by whom a given resource should be accessed. A security context is typically shown as a string consisting of three or four words. Each word specifies a different component of the security context, namely the user, role, type, and level of that file or process. Each word is separated by a colon.
  
== system_u:object_r:httpd_exec_t:s0 ==
+
The security context for files is stored in the form of an [http://www.wikipedia.org/wiki/Extended_file_attributes extended file attribute]. A file's security context may be viewed using <code>[http://linux.die.net/man/1/ls ls(1)]</code> with the <code>-Z</code> option. It may be modified using <code>[http://linux.die.net/man/1/chcon chcon(1)]</code>, whose syntax is intentionally similar to <code>chmod</code>. A file's security context is associated with the file's [http://www.wikipedia.org/wiki/inode inode] and not the location or directory; this ensures that security contexts will remain the same regardless of whether a file is moved or renamed.
  
Everything in SELinux revolves around the Security Label, or security context.  Every Subject (Processes) and Object (Usually files on the computer) has a security context associated with it. This context has different names depending on what it is attached to. It is called a file_context when it is associated with a file.  It is sometimes called a domain when associated with a process.
+
Some filesystems do not support extended file attributes. In these cases, the [[kernel]] provides a default security context for that filesystem. For example, all files on an NFS filesystem are labeled "<code>system_u:object_r:nfs_t</code>".
  
File context are stored with the Inode in an extended attribute on systems that support extended attributes.  This works the same way as DAC Protections and ACL's. In that the security of the file is based information stored at the Inode not the path to the file.
+
== Fields ==
 +
The security context is comprised of four fields: ''user'', ''role'', ''type'', and ''level''. All fields are required, except for the level.
  
On file systems that do not support extended attributes the kernel provides the file context.  So for example there is a rule on a SELinux box that says all files in an NFS mounted file system are labeled system_u:object_r:nfs_t.
+
=== User field ===
  
Now lets look at what makes up a security context.
+
The first component of the security context is the "SELinux User" component.  This component can be thought of as a way of grouping roles.
 +
SELinux Users can have multiple roles that they can reach, and then in those roles they can reach multiple types.  Three users that you will usually see on the system are "user_u", "system_u" and root.  The user_u is the default SELinux User for a logged in user on a system.  "system_u" is the default User for processes started during the boot up process.  IE they were never started by a user.  "root" is the SELinux user that you get when you login at the console as "root".  In targeted policy the user component is really not important.  It is more important in MLS and Strict policy machines.  On a file the user component specifies the SELinux user that created the file.  On the initial system files are labeled as system_u.  Or if you relabel they will get set back to system_u.  By convention all default SELinux Users end with a "_u" except for root.  Originally if you wanted to map a Linux User to an SELinux user, you would create a SELinux user name with the same name as the Linux User.  This is why the root user does not end in a "_u".  In newer versions of SELinux we have added a mapping file "seusers" which allows you to map Linux Users to SELinux Users without having to create a lot of new SELinux Users.
  
The security context is made up of 3 or 4 components separated by “:”
+
=== Role field ===
I want to talk about these components starting at the last and working my way back to the first.
+
  
== 4th Component: MLS Component ==
+
The second component of the security context is the Role field.  This field is only really relevant on processes or domainsThe role field on a file is always object_r, and really has no meaning other than as a place holder.  On a process you would usually see a role like system_r or sysadm_r.  Roles are used to group security types.  So you can specify in policy which roles are able to execute which types.  This is the basis of "Roles Based Access Control" (RBAC) in SELinux.  RBAC is not really used in targeted policy, but becomes more important in Strict and MLS policy.  MLS Policy also contains sysadm_r, staff_r, and secadm_r.  Roles by convention end with a "_r".
The 4th component is the MLS (Multi Level Security) field which is not supported in RHEL4 or Fedora Core 4It is first showing up with Fedora Core 5, although it has been in SELinux in the previous versions, it was never turned on.
+
  
This component is used in all policies shipped with Fedora Core 5.  On strict and targeted policies we refer to this as the MCS (Multi Category System) Field.  Unfortunately this field can contain a ":".  The syntax of this field can look something like s0-s15:c1,c2.  But I will put off talking about
+
=== Type field ===
this syntax until a later date.  Most files by default are labeled s0, sometimes referred to as SystemLow.  Fortunately SELinux provides a translation library (libsetrans) that replaces the codes in this field with a more human readable form.  So something like s0:c1,c2 might be show up to the user as PatientRecord,CompanyConfidential.  On a targeted  or strict policy machine s0 translates to "", so almost all files will not even show the fourth field.
+
 
+
== 3rd Component: Types ==
+
  
 
The 3rd component of the security context is the Type component, for example /usr/sbin/httpd is labeled with a type of “httpd_exec_t".
 
The 3rd component of the security context is the Type component, for example /usr/sbin/httpd is labeled with a type of “httpd_exec_t".
Line 27: Line 25:
 
In my opinion this is the most important field in the SELinux security context.  This is the heart of SELinux Type Enforcement.  Most of the policy rules in SELinux revolve around what subject types have what access to which object types.  By convention this component always ends in a "_t".
 
In my opinion this is the most important field in the SELinux security context.  This is the heart of SELinux Type Enforcement.  Most of the policy rules in SELinux revolve around what subject types have what access to which object types.  By convention this component always ends in a "_t".
  
== 2nd Component: Roles ==
+
=== Level field ===
 +
The 4th component is the MLS, or Multilevel security, field which is not supported in RHEL4 or Fedora Core 4.  It is first showing up with Fedora Core 5, although it has been in SELinux in the previous versions, it was never turned on.
  
The second component of the security context is the Role fieldThis field is only really relevant on processes or domains.  The role field on a file is always object_r, and really has no meaning other than as a place holderOn a process you would usually see a role like system_r or sysadm_rRoles are used to group security typesSo you can specify in policy which roles are able to execute which types.  This is the basis of "Roles Based Access Control" (RBAC) in SELinux.  RBAC is not really used in targeted policy, but becomes more important in Strict and MLS policy. MLS Policy also contains sysadm_r, staff_r, and secadm_rRoles by convention end with a "_r".
+
This component is used in all policies shipped with Fedora Core 5.  On strict and targeted policies we refer to this as the MCS (Multi Category System) FieldUnfortunately this field can contain a ":".  The syntax of this field can look something like s0-s15:c1,c2But I will put off talking about
 +
this syntax until a later dateMost files by default are labeled s0, sometimes referred to as SystemLowFortunately SELinux provides a translation library (libsetrans) that replaces the codes in this field with a more human readable form.   So something like s0:c1,c2 might be show up to the user as PatientRecord,CompanyConfidentialOn a targeted  or strict policy machine s0 translates to "", so almost all files will not even show the fourth field.
  
== 1st Component: Users ==
+
== Advanced ==
 +
The method used by SELinux to associate security contexts with inodes is also used by DAC protections and ACL's.
  
The first component of the security context is the "SELinux User" component.  This component can be thought of as a way of grouping roles.
+
[[Category:SELinux]]
SELinux Users can have multiple roles that they can reach, and then in those roles they can reach multiple types.  Three users that you will usually see on the system are "user_u", "system_u" and root.  The user_u is the default SELinux User for a logged in user on a system.  "system_u" is the default User for processes started during the boot up process.  IE they were never started by a user.  "root" is the SELinux user that you get when you login at the console as "root".  In targeted policy the user component is really not important.  It is more important in MLS and Strict policy machines.  On a file the user component specifies the SELinux user that created the file.  On the initial system files are labeled as system_u.  Or if you relabel they will get set back to system_u.  By convention all default SELinux Users end with a "_u" except for root.  Originally if you wanted to map a Linux User to an SELinux user, you would create a SELinux user name with the same name as the Linux User.  This is why the root user does not end in a "_u".  In newer versions of SELinux we have added a mapping file "seusers" which allows you to map Linux Users to SELinux Users without having to create a lot of new SELinux Users.
+

Latest revision as of 18:57, 29 August 2012

The SELinux security context of passwd(1), as shown by the command: ls -Z /usr/bin/passwd

A security context, or security label, is the mechanism used by SELinux to classify resources, such as processes and files, on a SELinux-enabled system. This context allows SELinux to enforce rules for how and by whom a given resource should be accessed. A security context is typically shown as a string consisting of three or four words. Each word specifies a different component of the security context, namely the user, role, type, and level of that file or process. Each word is separated by a colon.

The security context for files is stored in the form of an extended file attribute. A file's security context may be viewed using ls(1) with the -Z option. It may be modified using chcon(1), whose syntax is intentionally similar to chmod. A file's security context is associated with the file's inode and not the location or directory; this ensures that security contexts will remain the same regardless of whether a file is moved or renamed.

Some filesystems do not support extended file attributes. In these cases, the kernel provides a default security context for that filesystem. For example, all files on an NFS filesystem are labeled "system_u:object_r:nfs_t".

Contents

[edit] Fields

The security context is comprised of four fields: user, role, type, and level. All fields are required, except for the level.

[edit] User field

The first component of the security context is the "SELinux User" component. This component can be thought of as a way of grouping roles. SELinux Users can have multiple roles that they can reach, and then in those roles they can reach multiple types. Three users that you will usually see on the system are "user_u", "system_u" and root. The user_u is the default SELinux User for a logged in user on a system. "system_u" is the default User for processes started during the boot up process. IE they were never started by a user. "root" is the SELinux user that you get when you login at the console as "root". In targeted policy the user component is really not important. It is more important in MLS and Strict policy machines. On a file the user component specifies the SELinux user that created the file. On the initial system files are labeled as system_u. Or if you relabel they will get set back to system_u. By convention all default SELinux Users end with a "_u" except for root. Originally if you wanted to map a Linux User to an SELinux user, you would create a SELinux user name with the same name as the Linux User. This is why the root user does not end in a "_u". In newer versions of SELinux we have added a mapping file "seusers" which allows you to map Linux Users to SELinux Users without having to create a lot of new SELinux Users.

[edit] Role field

The second component of the security context is the Role field. This field is only really relevant on processes or domains. The role field on a file is always object_r, and really has no meaning other than as a place holder. On a process you would usually see a role like system_r or sysadm_r. Roles are used to group security types. So you can specify in policy which roles are able to execute which types. This is the basis of "Roles Based Access Control" (RBAC) in SELinux. RBAC is not really used in targeted policy, but becomes more important in Strict and MLS policy. MLS Policy also contains sysadm_r, staff_r, and secadm_r. Roles by convention end with a "_r".

[edit] Type field

The 3rd component of the security context is the Type component, for example /usr/sbin/httpd is labeled with a type of “httpd_exec_t".

In my opinion this is the most important field in the SELinux security context. This is the heart of SELinux Type Enforcement. Most of the policy rules in SELinux revolve around what subject types have what access to which object types. By convention this component always ends in a "_t".

[edit] Level field

The 4th component is the MLS, or Multilevel security, field which is not supported in RHEL4 or Fedora Core 4. It is first showing up with Fedora Core 5, although it has been in SELinux in the previous versions, it was never turned on.

This component is used in all policies shipped with Fedora Core 5. On strict and targeted policies we refer to this as the MCS (Multi Category System) Field. Unfortunately this field can contain a ":". The syntax of this field can look something like s0-s15:c1,c2. But I will put off talking about this syntax until a later date. Most files by default are labeled s0, sometimes referred to as SystemLow. Fortunately SELinux provides a translation library (libsetrans) that replaces the codes in this field with a more human readable form. So something like s0:c1,c2 might be show up to the user as PatientRecord,CompanyConfidential. On a targeted or strict policy machine s0 translates to "", so almost all files will not even show the fourth field.

[edit] Advanced

The method used by SELinux to associate security contexts with inodes is also used by DAC protections and ACL's.