danwalsh

I will follow the suggestion of one of the replies and try to do some blogging on using SELinux from the System Administrators point of view.

I gave a course at the SELinux Symposium on using SELinux in Red Hat Enterprise Linux 4.

ftp://people.redhat.com/dwalsh/SELinux/ManageRHEL4.odp

After the talk, I was amazed at how many people came up to me and said they wish they had this talk before some of the more advanced talks.

In the early 80's when I went to college, Holy Cross, computers were the big thing on campus. Everyone thought they had to take a computer class in order to understand computing. Problem was that the college only offered PL1/Fortran classes. So we had lots of liberal arts students taking PL1 and Fortran classes so they would know what this computing thing was all about. They came away from the experience thinking that computing was hard. Of course I got a lot of free beer, for helping them write their programs. :^)

We are doing the same thing with SELinux. So lets take a step back and talk about some of the fundamentals of SELinux, from my point of view.

Security Context. system_u:object_r:httpd_exec_t:s0

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.

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.

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.

Now lets look at what makes up a security context.

The security context is made up of 3 or 4 components separated by “:”
I want to talk about these components starting at the last and working my way back to the first.

4th Component: MLS Component
The 4th component is the MLS 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 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.

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

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

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

1st Component: Users

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.

Tomorrow "How does SELinux enforce policy?"