Linux Security Modules

What we will learn?

• User dependent Security: DAC
• DAC
• LSM
• User-independent Security: MAC
• MAC
• Flow of command
• Types of LSM
• DAC vs MAC

How Linux is Secured?

If we talk about security in linux. Users, files and processes play an important role in protecting your OS. In short, the OS is all about files. Among them, few files are very critical and important, therefore they must be secure. According to me, securing your files or securing a running process is what security means in Linux. For accessing files or processes users must have permissions. Unlike root users, other users have restricted and limited permission. Securing files can be achieved in 2 ways: One is user dependent and another is user independent.

What does it mean by user dependent security?

Discretionary Access Control(DAC)

In the early days when security was dependent on users of linux, the user played the most important role in securing your environment. If the user is root, then it has unlimited access to files and processes, otherwise a normal user has restricted access or limited access. User-dependent means that access to files and processes requires permission of the user. If the user has the permission then it can access files and processes otherwise could not. Here the user may be owner or may not be owner of the file, or root user or any other user included to a group which has access to this file. Suppose if an attacker gets access to the root user then your system will be controlled by the attacker. Though getting root access is not easy, it's not an impossible task.
The terminology given for user-dependent security in the Linux world is known as Discretionary Access Control(DAC). According to definition, DAC (Discretionary Access Control) based access control is a means of restricting access to objects based(files, process,etc) on the identity of subjects or groups(users).

Example:

Let’s take an example and try to understand through it.
Suppose you are running a web server which hosts several websites. To allow access on websites we have to open several ports in the firewall. Hackers may use these ports to crack the system through the security exploits. And if that happens, hackers will gain the access permission of the web server process, as we know that port is associated with some web server that serves web pages. To serve web pages, usually a web server process must have read permission on document root and write permission on the /tmp and /var/tmp directory. With this permission of root associated with the web server, hackers can write malicious scripts in /tmp directory and execute it. From here, the system is now in control of the attacker. We saw how one infected process can cause a huge security risk to all services running on the server. So, the conclusion of the story is that the attacker got access to the root user through a web server user to write a script and execute it. So, now the question arises, Is there any way to protect ? Yes, it’s like a third party solution. The third party solution is none other than a policy known as Security Policies or Security Modules or Linux Security modules(LSMs).

Linux Security modules(LSM)

Since the policies are used for securing your environment that is why it is known as Linux Security based Policies or in more technical terms it is known as Linux Security Modules. Now, one more question arises is, where are these policies attached or hooked? In short these policies are fitted after DAC checks. To understand it in more detail, you need to understand how commands are executed. Until and unless you don't have an idea how commands are executed,then you won’t be able to know where the policy is being added.
For example, let's say a hacker after getting access to the root user wants to access files present in /etc directory to change its configuration as well also interested in seeing the confidential files such as passwd file and shadow file.
As we know that each and every user in linux is associated with some files or each file is associated with a user. Suppose there is a policy whose operation is to block some files from reading. After attaching that policy after DAC checks, the policy determines whether the user has permission to access that file or not; it will block opening of a particular file independent of any user trying to read it. One exciting solution for this is to secure linux by user-independent method. Basically, what user-independent means is, though the root user or any user has unlimited access but then also it can be denied from operation such as accessing files or processes, if external policy is applied. And the terminology used for user-independent or policy based security is known as MAC.

user-independent security

Mandatory access control(MAC)

Mandatory access control is a security method where what is allowed is explicitly defined by policy. A user(normal or root both) or program can not do any more than is allowed by the policy confining it.
MAC is of User-independent type security.
To understand it you need to understand the flow-chart.

Flow of open() system call:

The LSM framework is integrated into the kernel which provides each LSM with hooks on essential functions of the kernel. The diagram above shows coarse call flow of the “open()” system call invoked by some process –
As the user tries to open or see any file, it always triggers the open() syscalls function.
A process in the user space calls open() on the file path
The system call is dispatched and the path string is used to obtain a kernel file object and inode object. Inode table is nothing but you can relate it to your content in the first page of your copy. Remember in your childhood, you used to write chapter names and corresponding page numbers. So, similarly in inode table, file name and its corresponding address are provided.
The parameters and syntax of command are checked. If incorrect then error is returned.
If everything above goes fine. Then normal “Discrete access control” (DAC) file permissions are checked. What does it mean? It checks whatever operation is performed(like file access or process access), if the user has permission to execute it or not. Suppose a user is accessing a file, it will check if this user is the owner of the file, or is this user a member of a group which has permission to access this file or is it a root user. If it doesn't have permission then the system call is terminated and error is returned to user space.
Note: As we talked above, Since the attacker has the access of root user so it can easily pass the security till here.
Then questions arise where policy fits. Or where policy can be hooked. So, the answer is just after DAC checks. Now the attacker will face a problem because the next Security is user independent, i.e. linux security modules or linux security policies. Users from here onward, whether it's a root or normal, can only run those commands that are allowed to run from the policy.
To attach policy in a hook, a framework is used, i.e. the LSM framework. LSM frameworks provide hooks to attach your policy. As above we applied a policy which is to block all execution of binary files or accessing of any file or folder which are inside /etc directory. The policy blocks execution and the system is terminated and error is returned to the user space if a single LSM hook returns an error.
Finally, when all security checks pass, the file is opened for the process and a new file descriptor is returned to the process in the user space.

Types of LSMs

There are a total of 9 different types of LSM: SELinux , SMACK , AppArmor , TOMOYO ,Yama , LoadPin , SafeSetID , Lockdown , BPF. Out of which SELinux and AppArmor are popular one. SELinux is used in RedHat Linux distribution whereas AppArmor is used in Ubuntu and Suse.
Complexity: Different LSM have different languages to write those policies. And believe me, it’s hard to write those policies. Btw, until and unless you are a professional or Linux Administrator you don't need to add any policies. Because by default all necessary policies are already applied to your distribution system, but for that LSMs must be enabled.

DAC vs MAC

DAC (Discretionary Access Control) based access control is a means of restricting access to objects based on the identity of subjects or groups. For decades, Linux only had DAC-based access controls in the form of user and group permissions. One of the problems with DACs is that the primitives are transitive in nature. A user who is a privileged user could create other privileged users, and that user could have access to restricted objects.
With MACs (Mandatory Access Control), the subjects (e.g., users, processes, threads) and objects (e.g., files, sockets, memory segments) each have a set of security attributes. These security attributes are centrally managed through MAC policies. In the case of MAC, the user/group does not make any access decision, but the access decision is managed by security attribute or security policies.