DEV Community

Cover image for Linux For Cloud Engineers: Understanding SELinux
Kelvin Onuchukwu
Kelvin Onuchukwu

Posted on • Edited on • Originally published at practicalcloud.net

Linux For Cloud Engineers: Understanding SELinux

Visit my website: Practical Cloud for more posts and projects on Devops and Cloud engineering.

I find that most Cloud Administrators, DevOps engineers and even some sysadmins shy away from the subject of SELinux.
This is not encouraging, giving the fact that a properly implemented SELinux policy can greatly reduce the attack surface across our Linux-based EC2 instances and on-premise systems.

The best way to think of SeLinux is to think of it as an access control mechanism, which implements Mandatory Access Control. This MAC is implemented on top of Discretionary Access Control (DAC) which is built into all Linux systems. What this effectively means is that SELinux will not grant a permission that has been denied by DAC. It can only deny permissions that might have been granted by your Discretionary Access Control.
In addition to implementing MAC, you can argue that SELinux implements Role-Based Access Control (more on that in the later paragraphs).

Discretionary Access Control can simply be thought of as the read, write and execute (rwx) permissions for users, groups and 'others' that you define for your files across your filesystem.

The purpose of SELinux is to regulate the permissions granted to a process and how it accesses files within a Linux environment. Such that a process will always run under the permissions granted to it, no matter if it is started by a privileged or non-privileged user. In essence, a process will only run with the rights necessary for it to perform its function.

Suppose an application running in our EC2 instance - with root privileges - is compromised by a hacker, the hacker can not be able to cause major damage to our environment. This is because even though the application is running under the context of the root user, our SELinux policy has restricted the permissions granted to this application and the running process is not able to access resources beyond which has been granted to it by an appropriately configured SELinux Policy.

There are quite a few terminologies associated with SELinux.
A few of them are; users, roles, subjects, objects, domains, types and type enforcement.

An SELinux user executes a process. That process, is known as a subject.
This could be a user creating a directory, or modifying a file.
So basically, a subject is a running process (a daemon).

But in order for a user to execute a process, it must have access to a role and that role itself must have access to the subject.
This is where Role Based Access Control (RBAC) comes in. A role acts like a bridge between a user and a subject. The role defines which users can have access to itself. Also, the role has a defined list of subjects that it can access.

An object in SELinux is anything that a subject acts upon. This could a file, a directory, or even a server.
Domains are contexts for subjects while Types are contexts for objects.

Bye for now and thank you for reading.

Top comments (0)