A perspective on SELinux

Many people think SELinux is complicated. SELinux is actually beautifully simple if you keep in mind that it
allows you to manage security very granular in computer systems which are very complex.

In this article i will try to explain the basics of SELinux. The things you need to know to find your
way around the SELinux environment.

SELinux can roughly be categorized in a few separate parts (ordered by importance):

1. The SELinux framework.
* 2. The tools to manage SELinux.
* 3. The policy.

In this article i will talk about The SELinux framework and the Type enforcement security model.

Knowledge of the SELinux framework is fundamental. If you are familiar with this it will enable you to
find your way around the rest.

Knowledge of the different SELinux security models is also important in this part i will talk about how
the Type enforcement security model fits into the SELinux Framework.

To learn about SELinux you have to know a bit about security and about computer systems.

What is security? Security is managing parties in an interaction. So for example if you want to secure a
human sitting on a chair. You have to manage the human and the chair. The human interacts. this is
called a subject, the chair does not interact and this is called an object. You could create policy that allows
the human to sit on the chair but not stand on it. Standing on it may cause it to break.

How do computer systems work? Computer systems are similar. processes are like humans. We call them
agents. A process therefore is a subject just like the human in my chair example. Processes interact. A
file in a computer system does not interact. The subject interacts with it. A file is a object. In a
computer system there are many classes of objects just like there are many kind of classes of object in
real life. My example was a chair but it could have been a bed or a bike etc. In a computer system a
object could be a file or a network port. Generally keep in mind that subjects interact and object get
interacted with.

So simplified:
Real life: human, chair, sit
Computer system: process, file, read

Humans can be categorized in many classes, the most obvious is man and woman but there are many types of
different humans. Processes in a computer system can also be categorized in many classes, for example a
process of a user or a process of a program.

Chairs can also be categorized in many classes. Theres rocket chairs and theres oother chairs as well,
but they are all chairs and objects. Objects in computer systems can also be categorized. There are
files and directories etcetera.

If you want to manage all these subjects and objects than you will want to categorize them. So that you
can create policy for each.

Subjects interact, objects dont. Lets look at some policy for the examples i gave.

real life:
allow man chair:rocket_chair sit;

computer system:
allow user file:dir read;

So in the real life example we allow a subject: human of the type: man to sit on a chair that is of the
class rocket_chair.

In the computer system example we allow a subject: process of the type user to read a file that is of
the class dir.

Our rule start with allow to signal that we want to allow the rule that follows, than follow our source
of the interaction. Which is always a subject since subject interact and object do not. Next is the
target. targets can be either subject or objects. subjects can interact with other subjects. for example
a man talking with a woman. Next is the class of the target. in our man/woman interaction the class
would of the target human would be woman. The last part defines the permission. What interaction is
allowed? in our man/chair example the man is allowed to site on a rocket_chair in our computer system
example the user process is allowed to read a dir. In our recent man talks to woman example we allow a
man to talk to a woman.

So back to SELinux. How does SELinux relates to all this. SELinux is for a large part in the kernel. It
is a framework. That means that SELinux provides us with some attributes so that we can create policy to
define what may and what may not. The attributes that SELinux provides are classes and permissions.
SELinux knows the classes of the parties involved in interaction in a computer system. It knows
subjects and the different classes of objects. SELinux also knows how subject interact with the
different object. In the real life example: SELinux knows theres a human interacting with a chair. It
knows the chair is a rocket chair and it know in what ways humans interact with chairs (sit for example)

So the framework provides us with the attributes to create rules. What it cannot do is make further
destictions between different subjects and objects. And to be able to manage everything we must make
distinctions as much as possible. This is what policy authors do. They make categorize sources and
targets in an interaction. for example. SELinux knows a human wants to site in a chair. It even knows it
is a rocket chair. But what if we want to make a destinction between a yellow rocket chair and a red
rocket chair? We want to be able to allow the human to site in the red rocket chair but not the yellow
one. SELinux framework does not know the color, we do. This is where types come in.

Policy authors assign types to subjects and objects. so in the real life example:

allow human chair:rocket_chair sit;

allow human_man_type red_chair_type:rocket_chair sit;

In the computer system:

allow process file:dir read;

allow user_process_type home_file_type:dir read;

Types allow us to further categorize the parties in an interaction.

If sufficient for now to know that the SELinux framework provides us with the classes and permission
attributes and that it allows us the further categorize the source and target in an interaction, be it
subjects or objects.

Type enforcement is a model where policy is enforcement for interaction between the types of the parties
involved. The types can be defined by the policy author and the best types depend on the environment.

In a computer environment you might want to make a destinction between a log file and a library file, a
program or a user. In a real life environment you might want to make a destinction between man or woman,
red rocket chair or yellow rocket chair. It depends on what colors rocket chairs exist in you
environment. Types enable us to define the properties of our environment.

By default all interaction is forbidden. if we want to allow something we have define what is allowed.
If there are many types and classes of parties in interaction in an environment you might be able to
imagine to amount of rules required to manage all this. For now it is sufficient to know that there are
also ways to group or tag different types.

If you want a human to be able to sit on all colored rocket chairs you could for example tag the
red_chair_type and the yellow_chair_type to be colored_chair_types and use the tag to make one single
rule for both colored chairs.

allow human_man_type colored_chair_types:rocket_chair sit;

So that is a very important thing to understand about SELinux and security in general. The enforcement
of types is the most important security model of SELinux.

Besides the "allow source target:target_class permission;" rules, there is another thing to understand
and that is called a type transition. You can make one type transition to another type.

For now it is suffice to know that subject and object types can be triggered to change. Subject types
can change via rules that define what should happen if a process executes a file and object
types can transition via rule that define what should happen if a file is created under a certain
parents type.

Type transitions help you futher categorize parties which will let you define rule for types in certain scenarios.

This is the basics about SELinux. Types are configured by policy authors. The have special meanings and those meanings can vary per
policy. So the only thing that really always applies are classes and permissions they stay the same. Types are defined by humans and
to learn what a certail type is allowed you would have to reference the policy to determine that.

And that is want you we are often confronted with, types. rules that govern how one type can interact with another. What we dont know
is what a certain type of a subject is supposed to be allowed to do to a certain type of a object.

These things can be figured out by referencing the policy and asking yourself the question what is the meaning of the type? what are
its properties? This is what makes SELinux environments complex because policy is based on a policy authors vision on a system. And
that vision may differ per policy model and environment.

SELinux itself is not complicated but if you want to manage a complex system you will have to create many different types and thats
where SELinux gets complex. If you have a simple system to manage than SELinux will also be simpeler. If you have a simple security
goal on a complex system you may also be able to implement a simpler policy that is targeted towards just reaching your simple
security goal.

Eventually its all just subjects, objects, classes and permissions when it comes to the SELinux framework and the type enforcement
security model.

The more granular the policy to govern how subject can interact with objects gets,the complexer selinux gets. But this is the strenght
of SELinux: it allows you to define very granular what is allowed and what not in a system.

Blame the policy author and the policy for the complexity of managing your Security-Enhanced Linux ( i bet the policy author will
blame Linux ;) )

A quick note about the tools:

What are the tools for:

labeling objects
parsing access vector denials
translating access vector denials to policy
finding suggestions to solutions for access vector denials
finding what type a object should have
changing types of objects
restoring types of objects
searching rules in the policy database
mapping linux logins to subject types