rsbacl5s.gif (2243 Byte)  

Rule Set Based Access Control (RSBAC) for Linux - Why you need RSBAC


External link: read why the Adamantix Project prefers RSBAC for access control.

Why RSBAC?

You probably already read the RSBAC overview. So why do you need such a system?

Linux systems, as many others in the Unix family, have a well-known lack of access control. First of all, there is the small granularity of discretionary access rights, only dividing between read, write and execute rights for file owner, file group members and all others.

The fact that access control relies on a file owner's discretion already leads to various problems, like the level of trust that has to be put in a user, the vulnerability from malware working on behalf of a user, etc. Also, there is hardly any logging of user activities possible, making it even harder to detect malicious accesses.

The worst problem is the system administrator account 'root'. Many system tasks are only allowed to be done by this user, even many network services have to be started or, worse, run as root. The root account, however, has full access to every object in the system. It is easy to understand why so many Unix family systems have been compromised locally or by remote access.

Recent Linux kernels additionally implement a privilege scheme, which splits the root user's special rights into a set of single rights, called capabilities. These rights are given to a process based on the parent process and the executable that is run.

However, while these capabilities can distinguish between some access types, they are mostly ignorant of the object that is to be accessed, e.g. CAP_DAC_OVERRIDE gives full read and write access to all files and devices on the system. As a result, many administration tasks still have to be done with too many access rights. Another disadvantage is the fixed access control model, which cannot easily be changed or replaced.

The RSBAC framework gives detailed access control information, and you can implement almost any access control model in it, e.g. as a runtime registered kernel module. Also, there is a powerful logging system which makes intrusion attempts easily detectable.

RSBAC comes with several fully functional access control modules, e.g. Bell-LaPadula (MAC) or Access Control Lists (ACL). You just have to choose which ones suit your needs best - often a combination is the best choice.

To give you an example: With Role Compatibility (RC) model, you can protect all executables and configuration settings against *any* user, including root (in case of root exploits). Configuration changes or accesses to /etc/shadow etc. might only be done with certain programs that got a specific clearance for that.

Additionally, RC can encapsulate most daemons running on a systems so that they have exactly the type of access to every single object that is absolutely necessary. This way, a buggy daemon cannot harm the system at all, not even harm another daemon - apart from denial of service by overloading.

Now compared to Linux capabilities: You still have to rely on a daemon dropping privileges as necessary, and you still cannot tell which file may be accessed by this program and which one not. An exploit of a root daemon with DAC_override still leads to full access to all files, and thus to a full system compromise.

If access is denied, noone will notice - there is no logging for that. If a program gets infected or trojanized, noone will notice - there is no protection and no logging.

Did you ever wonder what all these huge daemons do on your system? Did you know that e.g. apache reads /etc/passwd? How many libraries, config files and programs are involved in a simple login? RSBAC will show you - if you want to.


Questions, tips, etc.

27-Aug-04, -ao