Security-Enhanced Linux (SELinux) is a set of patches to the Linux kernel and some userspace utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel in contrast to standard UNIX discretionary access control (DAC).
A Linux kernel integrating SELinux enforces policies that confine programs' and system servers' access to files and network resources. This confinement mechanism operates independently of the traditional Linux (discretionary) access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
With SELinux incorporated, files (including directories, devices) and network (TCP/UDP) ports, are referred to as objects. Processes, such as a user executed commands or web browsers (pretty much all userspace applications), are referred to as subjects.
To help you get the better understanding of how this works, let's take a look at few examples...
The following is an example of permissions formed by standard discretionary access control (DAC) which is default in all Linux systems:
user $ ls -l funtoo.file -rwxrw-r--. 1 funuser fungroup 0 Sep 16 07:14 funtoo.file
In this example, the first three permission bits, rwx, control the access "funuser" user (the owner) has to funtoo.file. The next three permission bits, rw-, control the access "fungroup" group has to funtoo.file. The last three permission bits, r--, control the access everyone else has to funtoo.file, which includes all users and processes.
Now let's take a look at the same file labeled with SELinux' mandatory access control (MAC):
user $ ls -lZ funtoo.file -rwxrw-r--. 1 funuser fungroup unconfined_u:object_r:user_home_t 0 Sep 16 07:14 funtoo.file
As you can see, we now have 3 additional labels:
- unconfined_u (user)
- object_r (role)
- user_home_t (type)
These 3 labels together are called the SELinux context, and are viewed with ls -Z command. This context is used to make access control decisions.
With DAC, access is controlled based only on Linux user and group IDs.
Keep in mind that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.
Let's take a look at another example...
Here we'll check an ID of a user in a system without SELinux:
user $ id uid=1000(funuser) gid=100(users) groups=100(users),10(wheel)
Now let's do the same on a SELinux enabled system:
user $ id uid=1000(funuser) gid=100(users) groups=100(users),10(wheel) context=unconfined_u:unconfined_r:unconfined_t user $ id -Z unconfined_u:unconfined_r:unconfined_t
As you can see, the same contexts are applied to users as well.
On SELinux governed systems there are 2 types of users:
- Standard Linux users
- SELinux users
SELinux users are part of SELinux policy. Linux users are mapped to SELinux users.