Part 2: The SELinux Model

(**In Simple Terms**, so please don’t beat me up if I’ve missed out a bit of complexity!)

SELinux has 2 parts. Context labels on each file in the file system and a policy. If something doesn’t work, you usually have 2 options: relabel part of the FS or modify the policy in some way.

The context is relatively simple and represents what processes may access the file, and whether the access is read only or read-write.

Context labels are completely independent to the traditional *nix user+group permissions model and the test is applied in sequence with the traditional permissions. So just because a transaction is allowable under SELinux the traditional permissions may still prevent access for any given user.

In order to check if a transaction is allowable, SELinux looks at the process running the transaction and the context, and checks these against the policy.

The policy is basically a matrix of what is allowable by which process.

For example, Apache or another HTTPd can view and alter files in /var/www but not in /var/lib/mysql , and vice-versa for mysqld.

So one can imagine there is a classification task, sorting processes into process classes, e.g. web, database, mail, user-applications etc.

… And then contexts needs to be defined (to account for all the and/or combinations)

… And then a labelling task – securing the right sections of the filesystem.


a. The basic pre-installed policy works pretty well.

b. It’s just another layer of the onion. A backstop to protect against application vulnerabilities and inappropriate filesystem permissions, so it doesn’t have to be /perfect/.