Serious Security for Linux?
11 - 22 min read
Feb 17, 2000
Copyright license terms available at
Originally written for /
Recently many Linux and Unix detractors have been harping on the fact that Linux's security model is based on an old and archaic way of doing business. Open-source advocates who are trying to get better security commonly point to Open BSD as their platform of choice. Linux has slowly been evolving extra security features, such as capabilities added to the 2.1.x and 2.2.x kernels. Unfortunately, not a lot of software takes advantage of these new features.
In the US military and intelligence communities, commercial Unix vendors have traditionally sold special versions of their Operating Systems which use formal security models and conform to varying degrees to part of a set of documents called "The Rainbow Series" colloquially; particularly, the "Orange Book" which is about trusted host security, and the "Red Book" which is about trusted networking implementations.
What I'd like to do here is discuss an Open Source project called RSBAC (Rule Set Based Access Control) which attempts to bring a significantly higher level of security to the Linux kernel and operating environment. After the introduction, we'll interview the project's founder, Amon Ott, and see what the future holds for some *serious* security in Linux.
With a new RSBAC-enabled kernel running, and some of the security modules turned on, your Linux system starts to be significantly more choosy about who can access what. Most importantly, security attributes are the domain of a new "Security Officer" user-id, *not* the root user. More importantly perhaps, changing between users is now restricted to accounts which have permission to do so. This means that it is possible to shut down the ability to gain security officer, data protection officer, root, or any other user on the system.
RSBAC is basically a security framework. It contains kernel patches which add enforcement to any system call which either has a security context or may affect security, administration tools to manage the new security modules and properties of files, devices, and users.
The framework includes several modules, each of which we'll talk a bit about in turn.
Before we start our tour, I'd like to explain some terminology that will help us communicate. If you're familiar with secure operating systems, you can skip ahead to here.
Terminology
Object - An object on the system is basically a file, device, or other passive entity.
Subject - A subject on the system is basically a user, process or other active entity.
Capability - The ability of a process to perform certain functions. Current kernels allow programs running as root to drop all special root privileges or capabilities. For instance an FTP server could start as root, then drop all root-specific capabilities except the capability to open low-numbered ports such as port 20, the default FTP-DATA port.
Compartment - Think of a compartment as a container for objects and a permission for subjects. For instance, if we have a compartment for "unclassified" data, and a compartment for "secret" data, people with access to the "unclassified" compartment would not be able to access data labeled as "secret" and visa versa. People with access to both compartments could access both sets of data.
Discretionary Access Control (DAC) - Users are able to change the permissions or compartments of information at their discretion if they have access to the information. For instance a user with administrator access could allow an unprivileged user access to the system's shadow password file by changing the file permissions.
Mandatory Access Control (MAC) - The system enforces access to information based on the information's compartment or other criteria. So if the shadow password file mentioned above was labeled "Secret", the administrator could not allow a normal unprivileged user access to the file unless that administrator had special permission to change the file's attributes.
Rainbow Series - A set of U.S. Government books on information security topics, so-called because each volume had a different colored cover. Some are available on-line at:
Orange Book - The Trusted Computer Systems Evaluation Criteria (TCSEC). A criteria for building trusted systems to process classified information.
Red Book - The Trusted Networking Implementation (TNI). A criteria for building TCSEC systems in a network environment, as well as trusted networks.
SSH - Secure Shell, a program for accessing computers remotely which encrypts the traffic including the user and password information.
IPSEC - Internet Protocol SECurity. An extension to TCP/IP which allows encryption to protect all of the traffic between hosts. Free/SWAN is the beginnings of a Linux IPSEC project.
CIPE - Cryptographic IP Encapsulation. A project to build fast but still encrypting IP routers. Information is available at: Home Page - Olaf Titz
setuid, seteuid - The system calls under Unix and Unix-like systems such as Linux which allow a process to change the ID it runs under.
CGI - Common Gateway Interface. A program run by a Web server. Poorly written CGI's are notorious for being used to compromise Web servers.
mod_user - An apache module which allows CGI programs to be run as a specific user who is logged in to the Web server.
Malware - Literally "bad ware", or bad software, such as a virus or Trojan Horse program written to attack a system.
RSBAC Modules - Short Tour
There is a much more comprehensive description of each module available on the RSBAC site. This is meant to serve as a brief overview.
Mandatory Access Control (MAC)
The MAC module implements up to 64 compartments. Any object can be assigned
a compartment or group of compartments. Any subject on the system
which tries to access the original object must also be assigned to the
same compartment unless that compartment is dominated by another. Traditional
Unix file system objects are assigned permissions with Discretionary Access
Control (DAC), so-called because the user can change ownership at his or her
discretion. MAC allows the system to ensure that something at a
classification of "Secret" can't be read or written to by anyone who isn't
in the compartment "Secret." Since the system enforces this, there's no
way for any but a specific user assigned access to a compartment by the
security officer to access that information.
Privacy Model (PM)
The privacy module allows certain data to be protected by its owner as
private. RSBAC includes sample source code to a simple medical application
which allows things like patient information to be stored on the machine
with restricted access for certain users. This module follows the rules of
the Federal German Privacy Law and the EU directive on privacy and was
developed in conjunction with the model's designer, Simone Fischer-Hübner.
Malware Scan (MS)
This module uses the RSBAC framework to protect the system against
corruption by known-bad things such as viruses and Trojan Horses. The
current module will detect the BlissA and BlissB viruses.
Role Compatibility (RC)
This module allows the creation of roles for access to targets of types
file/directory, device, process, IPC, and system control data. The roles are
defined for system administrator and role administrator and general user.
Additional roles may be defined by the role administrator. Each user has a
default role, and those roles are inherited by the user's subprocesses. By
default, root has a role of system administrator and security officer has a
role of role administrator. This may be changed at any time by the role
administrator.
Function Control (FC)
This module implements role-based access such as 'system administrator',
'general user', or 'security officer. This module is designed to be used
in conjunction with other modules.
Security Information Modification (SIM)
This is another role-based module that protects data which is classified as
security information and restricts access to it to users with the security
officer role. This module is designed to be used with other modules
Authentication Module (AUTH)
The Authentication module acts to enforce setuid-type actions.
All other modules, built-in or generated by using the framework use the
AUTH module to enforce their security models.
Access Control Lists (ACL)
The ACL module provides standard ACL-type services to restrict access to
targets by subjects on the system. The ACL module seems to hint at being
patterned after the Netware implementation. Group access and a menu
system for ACL management are still under development.
Interview with Amon Ott, RSBAC's creator
Recently, I had the opportunity to interview Amon Ott for Linuxsecurity.com,
and I'd like to share our discussion:
[Paul] What would you like to tell about the project and its participants?
[Amon] RSBAC is going on because of the fun it gives to see your own ideas working and appreciated. The project staff mostly consists of myself, Simone Fischer-Hübner and Vadim Kogan, with several people contributing with ideas, model analysis, bug reports, patches and good questions.
[Paul] RSBAC seems to be quite far along. Do you see it as nearly finished, or do you still have a lot more goals for the project?
[Amon] I started the RSBAC project as my master thesis in November 1996, and it has taken more than a man-year of work so far. Still, I have never considered it as finished, sometimes it is hard to make a checkpoint for a new release. I never ran out of ideas, and I am also getting good ideas from other people, e.g. from the RSBAC mailing list participants.
[Paul] One of the stated goals of the project is to achieve something akin to 'Orange Book B1.' Is there a specific reason that it's Orange Book rather than Red Book (Trusted Networking)?
[Amon] In my opinion, you need trusted systems to build trusted networks. So the first goal has to be building a trusted system, which is a difficult and complex task.
Trusted networking involves the use of untrusted intermediates, like network cables, reliable distribution of access control information, object synchronization over slow links etc. The complexity of a trusted network is far beyond that of a trusted single system.
One of the bigger items on my to-do-list is a change in representation of RSBAC socket objects, which are used for network access control. When this has been changed, it might be possible to distribute socket and other attributes as a first step for a kind of distributed RSBAC.
However, an Orange or Red Book label like B1 states that a system meets some military confidentiality requirements from more than ten years ago, and not that it is suitable or secure for a modern organization like an Internet webspace or access provider. These old fashioned labels are nowadays mostly important for governmental purposes - or for marketing, because they are much easier to handle than modern evaluation criteria like the Common Criteria.
[Paul] It would seem to me that if the MAC/Role system were extended to include things like network-based trusted paths, remote administration of RSBAC-enabled computers could be bounded quite well with SSH and IPSEC, do you have any plans in that direction?
[Amon] Encrypted Virtual Private Networks (VPNs), e.g. with CIPE, already work fine with RSBAC. Also, SSH can be used like any other login shell, if appropriate rights are set. So you can do remote administration, if you wish to do so and consider the other system as secure enough. The security burden is then placed on tested applications and administrators.
I won't push SSH, though, because it is still a commercial product. With IPSEC I have no personal experience yet, but with host authentication on both sides, transport level encryption and a good key management you can enhance your network security pretty much.
[Paul] Root traditionally has access to kernel memory. To change the game from an attacker's point of view from gaining root to gaining root and security officer wouldn't be a big win. Can you discuss how RSBAC protects the system from such compromise?
[Amon] Root does never have direct access to kernel memory. Instead, a process running in the name of user root is granted access to everything that is accessible via system calls. Now, every security relevant system call is (or at least should be) protected by access control. As kernel modules do get full memory access, loading of modules is also fully controlled.
In RSBAC, root is treated like a normal user. Specially, a root process can neither change its process owner nor access any object without explicit permission by the access control system. The AUTH (Authentication) decision module has been specifically designed to control the change of process ownership: Every process needs an explicit 'setuid capability' for a user ID to be allowed to change to this ID.
So if RSBAC administration restricts access control settings to e.g. user 'Security Officer', and only selected processes are allowed to run in the name of this special user, a root compromise will not be a big win anymore.
[Paul] The capability sets added to the recent Linux kernels seem to place the burden of security on application developers to use them. RSBAC, on the other hand traditionally could be used to only shore up a current system, or to develop trusted applications like the sample medical system provided on the Web site. Do you see anything like Apache's mod_user being extended to allow Web hosting with per-user capabilities or change-proofing HTML or database-backed servers?
[Amon] Once your web server process changes its user ID when serving from a special directory tree, e.g. using the suEXEC feature, it is easy to get fine-grained access control.
On the other hand you could modify or create a module to use RSBAC specific features, like changing RC role. The Role Compatibility (RC) model allows changing your role to another, compatible one. This changing can be used as a one-way change, with the second role's rights being set to an optimum for this CGI or directory tree. With CGIs, you don't even need to change a module, because the RC 'forced role' feature allows forcing another role for a process executing a specific file.
Of course, the usual RSBAC object protection mechanisms can also prevent any tampering with executables or database files.
[Paul] Ever since I first saw RSBAC, I've thought that a HOWTO-style document that showed securing a Web server to a level that a CGI program that called /bin/sh with any arguments couldn't be executed by a remote user would be a great goal. Is this possible with RSBAC, and do you expect to have such HOWTOs on the site?
[Amon] Securing a Web server has been possible for quite a long time. With the updated RC model in version 1.0.9 you can easily deny access for the Web server daemon (e.g. apache) role to anything outside its document tree. Also you can define one or more CGI roles which are forced for certain CGIs and have a completely different set of access rights. As a simple solution to your shell example just remove the EXECUTE right to the file type of your /bin/sh.
Access rights for RC roles can be defined down to single files with help of the new Access Control Lists (ACL) model, which has also been added in version 1.0.9. This model works similar to a well known traditional PC network system in its version 3.xx and is currently extended with comfortable group management. Menu based administration, which has been introduced some versions ago, has not yet been finished for ACL, but is one of the next items on our to-do-list. So you could easily allow execution of /bin/cp, but deny execution of /bin/sh.
RC administration examples, e.g. for securing Web servers and the login process, will be contained in a paper which is currently being written by Simone Fischer-Huebner and me. The sample scripts we developed so far are in the example directory of the 1.0.9 admin tools package. The paper will be put on the RSBAC homepage as soon as it is finished.
Documentation is a big problem with a limited amount of working time, but I hope I will find some volunteer for a bunch of HOWTOs soon.
[Paul] This is along the lines of assigning a MAC of INTERNET or UNTRUSTED to a Web-based user in my mind, and why I'm curious about trusted path, if we make the HTTP port completely untrusted, can we stop unauthorized exploits?
[Amon] I personally have a distrust of other hosts even within a local network, which is based on my knowledge about the difficulties with trusted networks. So the HTTP port is always untrusted for me.
What we can do with access control is raise the trust level by securing the host itself from unwanted access via untrusted channels like HTTP ports. This has to be done by encapsulation of the server process, because every such program can contain bugs.
[Paul] On the RSBAC mailing list, I see you asking for feedback, soliciting user opinions, and releasing code early and often. Pretty much the best model for Open Source development. Do you get much feedback or contributed code?
[Amon] We do not get feedback from many RSBAC users, and only very few are contributing with new ideas and patches. But you must never forget the complexity of the whole system - it is very difficult to find and report errors, if you are not sure about the correct behavior. What is strange for me is that I get quite a few mails from interested people, but hardly anybody writes to the mailing list, though there are many listeners.
On the other hand, too much feedback could easily result in a denial of service on our side. ;)
[Paul] Do you hope that one day RSBAC will be part of the mainstream kernel, or is your focus on more specific implementations?
[Amon] It would be handy for me to have the patch parts in the mainstream kernel, specially because it would save me from downloading and patching every kernel release. Apart from growing code size and
other people's aesthetics I see no reason against it, because the whole RSBAC part can be turned off with a single configuration switch and is constantly maintained.
Still, there are not many people yet who see the need for mandatory security enhancements in the kernel. This will change soon enough as Linux enters more and more into the server market. For me as well as many others a flexible system call hook, like the RSBAC enforcement mechanism, would be an important enhancement.
[Paul] RSBAC seems to have started as a thesis project. Is it still, or have you moved on? Do you get to work on it during the day?
[Amon] It has been started as a master thesis, and I am still using it for academic stuff. This is one reason why I keep adding new security models. But I have always wanted it to be useful in real systems possibly charging money for administration services or for developing a customer-specific security module.
After finishing my thesis, which took me about 20h per week for one year, I have continued working on it usually between 1 and 20 hours per week, sometimes even more. This is mostly done during the day, because I can make my own timetable within our small company and don't want to put a bigger burden on my social life.
[Paul] Electronic Commerce seems to be the hot topic of the day, and Linux is starting to gain some business momentum. Do you think that RSBAC could have a role in the future merge of both?
[Amon] I hope that Electronic Commerce will have a clear focus on security, especially privacy, some day. This can only be achieved with better security. RSBAC is one approach to make Linux servers more secure, so it might help. A big problem is the necessary trust of Electronic Commerce companies in the product, which can only be gained by good experiences.
[Paul] Do you currently deploy RSBAC-based firewalls or other systems, or can you explain what you use RSBAC for?
[Amon] I am configuring Linux firewalls for smaller companies, but none of these is running RSBAC enhanced kernels, though the newer ones prepared for RSBAC. It is difficult to make the manager of a small company aware of the advantages of RSBAC while keeping her or his trust in Linux firewalls on the level they deserve - and to make them pay for the additional administration work.
So if a customer asked me to build a RSBAC enhanced Linux firewall, I would gladly do that. In fact, my pre-configured firewalls usually contain the current RSBAC version and some settings, but so far it is switched off by default.
[Paul] Is there anything in particular that you'd like to see from the Linux community?
[Amon] Hopefully, Linux development will keep un-commercial and personal demand driven as long as possible, demands of people earning money from Linux services of course included. You have to afford your free programming somehow. See RSBAC as my contribution to the Linux idea.
From security point of view, security should have a clear advantage over efficiency whenever design decisions are to be done, but the keep-it-simple paradigm also holds.
[Paul] Will RSBAC stay a Linux-only project, or have you considered working with any of the Open Source BSDs?
[Amon] It has originally been designed to be easily portable. I already had someone asking how to port to BSD, but it is a lot of work and you need a lot of experience in BSD systems to do that. I have no BSD experience at all. So let's say, I would appreciate and help someone doing the port, but I won't do it myself. It might even be possible to port it to NT, if NT was open sourced.
[Paul] The administration menus are really helpful. RSBAC seems like the kind of project that could raise the bar in the Information Security arena well beyond what commercial vendors could provide without years of work. Some pre-built configurations and perhaps integration with some vendors would certainly speed up adoption, do you have any thoughts in that area?
[Amon] I know that at least one big Linux distributor has real interest in security enhancements and would spend some manpower to get it tested and built. Also, some hardware vendors see a demand from customers and might help.
Also, there is a project led by Vadim Kogan who is trying to work out a security targeted non-commercial Linux distribution with sample configurations. This distribution will also include RSBAC.
[Paul] The Malware module seems to be ready for starting anti-virus duty, was this added because you see a future threat to Linux, or to complete the model?
[Amon] I know of several Linux viruses, which have not yet been in the wild, e.g. the Bliss variants A and B are detected by this module. The current Linux access control makes spreading of Viruses and Worms rather simple.
The Malware model has been the first Linux kernel on-access scanner as far as I know, but it has been added mostly as a demonstration module for a scientific paper and Anti-virus companies. You would need a team of roughly a dozen people and good connections to keep your virus database and the scanner up to date.
The base idea was that every system in a network has to protect itself tamper-proof from inside the kernel, independent of all other systems. And of course we wanted to demonstrate the power of the RSBAC framework.
[Paul] With all the 'hacker challenge' hype recently, do you see a need or think it possible to configure an RSBAC box that's able to contain things like Web servers, bad CGI programs, or even open shell users?
[Amon] It would be an interesting experience. Put up an RSBAC box, give me (or better a team) SSH access to root and secoff accounts, and on we go. How about a try with open shell users, who are allowed to put up their own CGI scripts in their public_html dir? I don't know what will happen, but I'd like to see it done.
[Paul] Microsoft seems to have gone as far as fully implementing ACLs with NT, with role-based things like backup and administrator rights. Care to contrast Linux and/or RSBAC to their model?
[Amon] I am not familiar enough with NT ACLs to give a good comparison. The main difference probably is that RSBAC is only a framework, in which you can establish almost any access control model, and RSBAC will care for proper enforcement.
This said, we could begin to compare NT ACLs with RSBAC ACLs (the latter are certainly much more fine grained and have a better inheritance model) or the rudimentary NT roles with RC roles. The main strength of RSBAC lies not in a single model, but in the combination of different models applied to different areas of security.
[Paul] Is there anything else you'd care to add?
[Amon] I would recommend starting such a project to anybody who can stand the permanent extra work. It is great to get positive response from people around the world whom you do not even know at all, though this should never be your main reason.
In summary, it would seem that RSBAC is a serious, well-founded effort to bring formal and tested security mechanisms to Linux. It also is capable of serving as a framework for new security mechanisms such as virus detection which haven't been traditionally available on Linux.
There's room in the project for many contributions, including documentation, porting to other Open Source operating systems, creating and maintaining anti-virus and anti-Trojan databases and signatures and creating new security models. Quite possibly, someone may be interested in sponsoring work in the area of testing and verification work or open challenges.
The RSBAC homepage is at
The RSBAC mailing list can be joined by sending an e-mail containing the line "subscribe rsbac" in the body to
