Saturday, 25 August 2007

SELinux & Access Controls - 3

What is SELinux ?

SELinux was originally developed by the NSA. SELinux is an operating system based on Linux which includes Mandatory Access Control . With SELinux you can define explicit rules about what subjects ( users, programs ) can access which objects ( files, devices ). You could think of it as an internal firewall, which gives you the ability to separate programs and thereby ensuring a high level of security within the operating system. SELinux is implemented as a LSM, and utilises the LSM kernel interface.

So,What is LSM ?

SM ( Linux Security Modules ) is an extension of the Linux kernel which allows security systems to be easily added to the kernel.The LSM homepage is at lsm.immunix.org

Why should I run SELinux?

Because SELinux gives you the ability to secure processes from each other within the system. For example, if you have a web server on the Internet which is also serving Email and DNS then you would not want a vulnerability in the web server process allowing the attacker access to corrupt your DNS server. SELinux is one of the very few practical operating systems available which can provide such a level of protection.

What does SELinux do that others can't ?

In a conventional Unix/Linux system, access control is under the control of the user. The user choses the other users that may access the files that the user owns. SELinux is under the control of the security administrator. This includes the files that the user owns. Even if the user wants a specific other user to have access to a file, if that user is not in a domain containing the other user (ie, both are in the same domain) then the other user still cannot access the file. The difference is in mandatory access vs discretionary access. As far as the system files go, if all are carefully given approprate ACLs, then they can be protected. However, if the root accout is hacked, the files are still vulnerable. If a SELinux system is hacked, unless the hack itself contains an all powerful label/domain, the hack still doesn't have access to all of the files. Only those belonging to the domain of the hacked daemon.

How is SELinux works?

Security like file permissions or user account passwords are Discretionary Access Control (DAC) systems. They are referred to as “discretionary” because every object (files and directories) has an owner, access to objects is based on user identify, and users (the object owner or root) are able to–at their discretion–grant access to other users. In contrast, SELinux is a Mandatory Access Control (MAC) system. Access to objects is controlled by a system-wide policy, regardless of the ownership of any object, enforced by the kernel. Users, including the root user, cannot grant other users access to their objects in violation of the policy. Using a MAC security system requires a different mindset. When people first encounter a permission violation enforced by SELinux, they often try to diagnose the problem by checking the ownership of the file and the read/write/execute permissions on the object. But even if the ownership and permissions are correct, the access is still blocked. The user and file/dir ownership is not the deciding factor with SELinux, the policy is.

Why is this distinction important? Here’s an example. Let’s say that you’re running an http server for a retail web site paired with a mysql database containing customer data (including credit card information). The software that runs the web site has a security vulnerability. If someone breaks into the server, what’s the risk to your system? it’s just the web sever, right? Wrong! Suppose the attacker is able to obtain a root shell. With root on a non-SELinux system, he can access your credit card database. Once the attacker gains access through the web server, the whole system is at risk. If this same system was protected by SELinux, the user might be able to use the vulnerability to break into the web server, but he would be prevented from touching the database or any other parts of the system, even if he got a root shell. SELinux would only allow the http process to communicate with the database through the named pipe. In other words, with SELinux, you don’t trust the application–which may be buggy, insecure, or compromised–to secure itself. You rely on the SELinux policy.

This diagram illustrates the httpd web server example:

Fig 1. httpd web server example

SELinux provides security to a system in a way similar to a ship or submarine’s design. They are divided into multiple water-tight compartments. If the ship springs a leak in any one compartment, only that compartment will fill up with water.

The following diagrams illustrate this difference:

Fig 2. Discretionary and mandatory access control diagrams

Reference:

1- The UnOfficial SELinux FAQ

2- RedHat Magazine – SELinux step-by-step by Dan Walsh

3- NSA – what is new in SELinux

No comments: