Your visual how-to guide for SELinux policy enforcement | Opensource.com

Your visual how-to guide for SELinux policy enforcement

Posted 13 Nov 2013 by 

Daniel J Walsh (Red Hat)
Rating: 
(56 votes)
SELinux policy guide
Image by : 

opensource.com

submit to reddit

We are celebrating the SELinux 10th year anversary this year. Hard to believe it. SELinux was first introduced in Fedora Core 3 and later in Red Hat Enterprise Linux 4. For those who have never used SELinux, or would like an explanation...

SElinux is a labeling system. Every process has a label. Every file/directory object in the operating system has a label. Even network ports, devices, and potentially hostnames have labels assigned to them. We write rules to control the access of a process label to an a object label like a file. We call this policy. The kernel enforces the rules. Sometimes this enforcement is called Mandatory Access Control (MAC). 

The owner of an object does not have discretion over the security attributes of a object. Standard Linux access control, owner/group + permission flags like rwx, is often called Discretionary Access Control (DAC). SELinux has no concept of UID or ownership of files. Everything is controlled by the labels. Meaning an SELinux system can be setup without an all powerful root process. 

Note: SELinux does not let you side step DAC Controls. SELinux is a parallel enforcement model. An application has to be allowed by BOTH SELinux and DAC to do certain activities. This can lead to confusion for administrators because the process gets Permission Denied. Administrators see Permission Denied means something is wrong with DAC, not SELinux labels.

Type enforcement

Lets look a little further into the labels. The SELinux primary model or enforcement is called type enforcement. Basically this means we define the label on a process based on its type, and the label on a file system object based on its type.

Analogy

Imagine a system where we define types on objects like cats and dogs. A cat and dog are process types.

*all cartoons by Máirín Duffy

Image showing a cartoon of a cat and dog.

We have a class of objects that they want to interact with which we call food. And I want to add types to the food, cat_food and dog_food

Cartoon Cat eating Cat Food and Dog eating Dog Food

As a policy writer, I would say that a dog has permission to eat dog_chow food and a cat has permission to eat cat_chow food. In SELinux we would write this rule in policy.

allow cat cat_chow:food eat; allow dog dog_chow:food eat

allow cat cat_chow:food eat;

allow dog dog_chow:food eat;

With these rules the kernel would allow the cat process to eat food labeled cat_chow and the dog to eat food labeled dog_chow.

Cartoon Cat eating Cat Food and Dog eating Dog Food

But in an SELinux system everything is denied by default. This means that if the dog process tried to eat the cat_chow, the kernel would prevent it.

Likewise cats would not be allowed to touch dog food.

Cartoon cat not allowed to eat dog fooda

Real world

We label Apache processes as httpd_t and we label Apache content as httpd_sys_content_t and httpd_sys_content_rw_t. Imagine we have credit card data stored in a mySQL database which is labeled msyqld_data_t. If an Apache process is hacked, the hacker could get control of the httpd_t process and would be allowed to read httpd_sys_content_t files and write to httpd_sys_content_rw_t. But the hacker would not be allowed to read the credit card data (mysqld_data_t) even if the process was running as root. In this case SELinux has mitigated the break in.

MCS enforcement

Analogy 

Above, we typed the dog process and cat process, but what happens if you have multiple dogs processes: Fido and Spot. You want to stop Fido from eating Spot's dog_chow.

SELinux rule

One solution would be to create lots of new types, like Fido_dog and Fido_dog_chow. But, this will quickly become unruly because all dogs have pretty much the same permissions.

To handle this we developed a new form of enforcement, which we call Multi Category Security (MCS). In MCS, we add another section of the label which we can apply to the dog process and to the dog_chow food. Now we label the dog process as dog:random1 (Fido) and dog:random2 (Spot).

Cartoon of two dogs fido and spot

We label the dog chow as dog_chow:random1 (Fido) and dog_chow:random2 (Spot).

SELinux rule

MCS rules say that if the type enforcement rules are OK and the random MCS labels match exactly, then the access is allowed, if not it is denied.  

Fido (dog:random1) trying to eat cat_chow:food is denied by type enforcement.

Cartoon of Kernel (Penquin) holding leash to prevent Fido from eating cat food.

Fido (dog:random1) is allowed to eat dog_chow:random1.

Cartoon Fido happily eating his dog food

Fido (dog:random1) denied to eat spot's (dog_chow:random2) food.

Cartoon of Kernel (Penquin) holding leash to prevent Fido from eating spots dog food.

Real world

In computer systems we often have lots of processes all with the same access, but we want them separated from each other. We sometimes call this a multi-tenant environment. The best example of this is virtual machines. If I have a server running lots of virtual machines, and one of them gets hacked, I want to prevent it from attacking the other virtual machines and virtual machine images. But in a type enforcement system the KVM virtual machine is labeled svirt_t and the image is labeled svirt_image_t. We have rules that say svirt_t can read/write/delete content labeled svirt_image_t. With libvirt we implemented not only type enforcement separation, but also MCS separation. When libvirt is about to launch a virtual machine it picks out a random MCS label like s0:c1,c2, it then assigns the svirt_image_t:s0:c1,c2 label to all of the content that the virtual machine is going to need to manage. Finally, it launches the virtual machine as svirt_t:s0:c1,c2. Then, the SELinux kernel controls that svirt_t:s0:c1,c2 can not write to svirt_image_t:s0:c3,c4, even if the virtual machine is controled by a hacker and takes it over. Even if it is running as root.

We use similar separation in OpenShift. Each gear (user/app process)runs with the same SELinux type (openshift_t). Policy defines the rules controlling the access of the gear type and a unique MCS label to make sure one gear can not interact with other gears.

Watch this short video on what would happen if an Openshift gear became root.

MLS enforcement

Another form of SELinux enforcement, used much less frequently, is called Multi Level Security (MLS); it was developed back in the 60s and is used mainly in trusted operating systems like Trusted Solaris.

The main idea is to control processes based on the level of the data they will be using. A secret process can not read top secret data.

MLS is very similar to MCS, except it adds a concept of dominance to enforcement. Where MCS labels have to match exactly, one MLS label can dominate another MLS label and get access.

Analogy

Instead of talking about different dogs, we now look at different breeds. We might have a Greyhound and a Chihuahua.

Cartoon of a Greyhound and a Chihuahua

We might want to allow the Greyhound to eat any dog food, but a Chihuahua could choke if it tried to eat Greyhound dog food.

We want to label the Greyhound as dog:Greyhound and his dog food as dog_chow:Greyhound, and label the Chihuahua as dog:Chihuahua and his food as dog_chow:Chihuahua.

Cartoon of a Greyhound dog food and a Chihuahua dog food.

With the MLS policy, we would have the MLS Greyhound label dominate the Chihuahua label. This means dog:Greyhound is allowed to eat dog_chow:Greyhound and dog_chow:Chihuahua.

SELinux rule

But dog:Chihuahua is not allowed to eat dog_chow:Greyhound.

Cartoon of Kernel (Penquin) stopping the Chihahua from eating the greyhound food.  Telling him it would be a big too beefy for him.

Of course, dog:Greyhound and dog:Chihuahua are still prevented from eating cat_chow:Siamese by type enforcement, even if the MLS type Greyhound dominates Siamese.

 Cartoon of Kernel (Penquin) holding leash to prevent both dogs from eating cat food.

Real world

I could have two Apache servers: one running as httpd_t:TopSecret and another running as httpd_t:Secret. If the Apache process httpd_t:Secret were hacked, the hacker could read httpd_sys_content_t:Secret but would be prevented from reading httpd_sys_content_t:TopSecret.

However, if the Apache server running httpd_t:TopSecret was hacked, it could read httpd_sys_content_t:Secret data as well as httpd_sys_content_t:TopSecret.

We use the MLS in military environments where a user might only be allowed to see secret data, but another user on the same system could read top secret data.

Conclusion

SELinux is a powerful labeling system, controlling access granted to individual processes by the kernel. The primary feature of this is type enforcement where rules define the access allowed to a process is allowed based on the labeled type of the process and the labeled type of the object. Two additional controls have been added to separate processes with the same type from each other called MCS, total separtion from each other, and MLS, allowing for process domination.

 


Illustrations by Máirín DuffyGet the coloring book!

For more information on SELinux read my blog at danwalsh.livejournal.com and follow me on twitter @rhatdan.

submit to reddit

27 Comments

Joe Wulf

Dan,
Excellent article! Thank you.

R,
-Joe

Vote up!
12
Vote down!
0
Margarita

Hhhhhh this article is awesome )) thank you ^^

Vote up!
8
Vote down!
0
lakshmipathi

We need more like this, are you planning for (part-2) visual guide for writing SELinux policies too ? Thanks!

Vote up!
8
Vote down!
0
Humble

nice work !!

Vote up!
6
Vote down!
0
Rick

Thanks! I love articles with pictures and easy to understand analogies.
Awesome!

Vote up!
6
Vote down!
0
Mario_1

Awesome! Do you plan on publishing more like this?

Vote up!
6
Vote down!
0
Nick

But more importantly, how do I disable it? (every customer, ever)

Vote up!
4
Vote down!
0
mairin
Open Source Evangelist
Vote up!
8
Vote down!
0
Christopher Meng

Maybe he can add some 3rd party share buttoms so we can share this site to the world.

Vote up!
2
Vote down!
0
Robert

This is the best introduction to SELINX.(=read as PERIOD)
Simply the best.

I would like to see a follow up article where you dive into these concepts even more. And if you could also give MAC from FreeBSD some love:-)

Vote up!
4
Vote down!
0
Eddie G.

I guess because I'm "slow" or dense I cannot seem to grasp this concept at ALL! :o( I can get that there's two files that have different "Type" permissions...but then the TYPES have a "type" permission as well?.....Hmm.....I guess I'll just have to fork up the 2K and go to SKOOL for this one!...LOL!~

Vote up!
2
Vote down!
0
Germán

Thanks Dan and Máirín for this guide, it is awesome!

Vote up!
4
Vote down!
0
Uncle Geek

I've seen references to SELinux but never knew what it did. Now I have a fair idea.

Purina, please treat these cartoons as inadvertent free advertising, which they may be, rather than trademark infringements, which I suppose they are. As your 30+ year customer, you have my good will and that of lots of others. Don't mess it up with a letter like Canonical sent a couple weeks ago.

Vote up!
6
Vote down!
0
Rogerio Carvalho

Dan, Thank you, this article clarify my knowledge about SELinux.

Vote up!
4
Vote down!
0
Unidentified

Cutesy diagrams and jargon = patronizing gobblygook. I doubt this was helpful to any real novices.

Vote up!
0
Vote down!
-2
Fran Quero

Great article. A five years old kid would understand it. Congratulations!

Vote up!
0
Vote down!
0
Alok

Great one ..!

Vote up!
0
Vote down!
0
Gianluca

Thanks, good article

Vote up!
0
Vote down!
0
colin.riddel
Community Member

Thanks for making the complex understandable

Vote up!
0
Vote down!
0
Kettu

Excellent article!

Vote up!
0
Vote down!
0
LG

Neatly explained. Very good article....!

Vote up!
0
Vote down!
0
Suman Kumar Mandal

I had gone through many documents on this, but today after reading this i have got my many doudts clarified. Thank you for posting this article, hope to see more from you on this.

Vote up!
0
Vote down!
0
Gabriel

Daniel, this is an excellent guide! May I translate it to spanish and post it in my blog? (I will give you the credits of course)

Vote up!
2
Vote down!
0
Jason Baker
Open Source Sensei

As long as you give credit, you're welcome to reuse and remix this article. Most of the content on Opensource.com is licensed under a Creative Commons Attribution-ShareAlike license, giving you permission to adapt it for any purpose, even a commercial one!

Vote up!
2
Vote down!
0
karen
Community Member

Dear Santa,

Give selinux-policy for everyone's data, to limit government, and protect our privacy from evil corporate hackers, if it wouldn't be too much trouble.

Vote up!
0
Vote down!
0
asrob
Open Minded

Wow, it's a great article, thanks! :)

Vote up!
0
Vote down!
0
Lakshminarayana Chava

Excellent Article

Vote up!
0
Vote down!
0

Daniel Walsh has worked in the computer security field for almost 30 years. Dan joined Red Hat in August 2001. Dan leads the RHEL Docker enablement team since August 2013, but has been working on container technology for several years.  He has led the SELinux project, concentrating on the application space and policy development.  Dan helped developed sVirt, Secure Vitrualization.  He also created the SELinux Sandbox, the Xguest user and the Secure Kiosk.  Previously, Dan worked Netect/

What Docker 1.0 means for OpenStack