The basic principle of Linux security

Disabling SELinux is a common thing we find in many tutorials. Apparently it is to complicated so it is more common to disable it rather than understanding it. Actually it is not hard to understand. This article will go over the basic principles of Linux security.

Computers exist for over 80 years now. In the first days of computing access control typically meant that someone had a key to the room where the machine was located. In the 80s and 90s it was pretty much the same with Personal Computers. If there was only one user it wouldn’t make sense to think about things like file permissions or system users at all.

On the other hand there were UNIX systems that were designed as Multi User systems from the beginning. So thinking about security was essential. These systems were designed so that multiple users could use them simultaneously.

Nowadays even Personal Computers use multi user Operating Systems. Even Windows is a Multi User system today. The principles presented in this article apply to UNIX like systems as well as to Windows. Modern operating systems use the supervisor/user mode that is provided by our CPU (for a detailed explanation see the Wikipedia article about protection rings: https://en.wikipedia.org/wiki/Protection_ring). That means a process in our system is running in either of both modes. Kernel processes run in supervisor mode and have access to all of our hardware resources. Every other process runs in user mode.

The following command list all kernel processes.

ps --ppid 2 -o pid,cmd

Showing only processes that run in user mode:

ps --ppid 1 -o pid,cmd

As processes in user mode are not allowed to access resources (e.g. open a file) they have to ask the Kernel to do it. This is known as “system call”. It is up to the Kernel to decide whether it complies with a request or not.

That decision is what security is all about. Note: When it comes to the root user there is a common misconception. People tend to believe that his processes run in supervisor mode. Actually root is nothing more than an ordinary user. The only thing that makes root different from other users is that the Kernel is somewhat more generous with granting him access.

There are four mechanisms the Kernel can use to decide whether to grant access or not.

Discretionary Access Control

These are the file permissions that everyone is used to. See http://www.it-automation.com/2021/05/29/discretionary-access-control.html for a more detailed explanation.

Capabilities

Capabilities are attributes that are attached to processes. The Kernel grants or denies specific permissions based on theses attributes. Capabilities act like keys within the Kernel. For a list of capabilities see

man 7 capabilities

For instance if a process wants to change the IP address of an interface it needs to have the CAP_NET_ADMIN capability.

Mandatory Access Control

Mandatory access control is implemented with Linux Security Modules that act as a Kernel hook. There are different modules avilable. AppArmor and SELinux being are the most widespread ones.

Let’s take SELinux as an example and assume we want to run an Apache that serves some static html files. The Apache has to have an attribute (SELinux context) that denotes it as “webserver”. Our html files need to have an attribute (context) that denote them as “web content”. Finally we need to have a policy that grants “webserver” access to “web content”. That policy is mandatory hence the name Mandatory Access Control.

Access is only granted if a matching policy is found. Assume that the webserver tries to access some system binaries. As long as we don’t have a policy that explicitly allows that access the request will be denied.

Seccomp

Seccomp (secure computing mode) is a way to limit processes to specific system calls. If a process tries to make a system call that it is not allowed to do the Kernel will not just deny access but kill the process. Typically seccomp is used to build sandboxes which is useful for a multitude of use cases.

Typically we use a combination of those 4 mechanisms. All of them are quite easy to understand once we understand the basics.

The only way to disable SELinux without compromising security is init 0.

Contact