One of the many features Red Hat Inc. is pushing to the forefront of its impending Red Hat Enterprise Linux 5 (RHEL5)...
release is better integration with Security-Enhanced Linux, or SELinux, an implementation of mandatory access control using Linux Security Modules (LSM) in the kernel.
Fair or unfair, SELinux has earned a reputation for being overly complex. Supporters like Karl MacMillan, however, say this reputation reflects the fact that Linux is a full-featured operating system, and full-featured means complexity and greater control.
MacMillan is the co-author of SELinux by Example: Using Security Enhanced Linux. He sat down with SearchOpenSource.com recently to discuss the changes due in RHEL5, as well as how SELinux will have a more prominent -- and automated -- role in the operating system's future.
SearchOpenSource.com: SELinux has earned a reputation for being complex. What's being done in Red Hat Enterprise Linux 5 to ease that complexity?
Karl MacMillan: As far as addressing complexity, there are two challenges -- to create policy and then to deploy the policy. With the new loadable modules in RHEL5, the focus is on the second problem. How does one ship the product to third parties and allow administrators to make changes? Essentially, what happens with Security-Enhanced Linux is in order to address security issues that exist out there, you have to have a mechanism that controls all access on a system. When you think of normal Linux access control, you are dealing only with processor access, file systems, control interfaces and networking, and they are very far removed from the normal Linux access mechanism. For example, even if you control access to writing files that MySQL uses, MySQL is still attacked over the network or via interprocessor communication. People aren't used to dealing with all of the kinds of access that a complex program like MySQL needs, and more importantly, the interaction between [the accesses] gets complicated.
By controlling all operations, SELinux is exposing the complexities that happen on Linux systems. I'm not trying to give Linux a hard time for being complex. [After all,] Linux is a full-featured OS, and being full-featured comes with complexity. In order to develop policies, first you have to understand what kind of access an application needs. In RHEL5, there's SETroubleshoot. Every time an application requests access, this tool will alert the user, via a GUI application, email or message log, that an application has tried to access this file, at this time, and was denied.
Does the introduction of Xen and paravirtualization into Red Hat Enterprise Linux raise any new concerns as they relate to Security-Enhanced Linux?
MacMillan: I think by definition both will cooperate very well together. Xen divides up portions of the server using virtualization to reduce collation of services using one piece of hardware and with dedicated systems. Within those divisions, SELinux reduces things down to finer grains than Xen. On the same system, you are going to have MySQL as well as administration tools. The next step is that users want to be able to apply the same kind of control over access that they have with SELinux at the Xen hypervisor level. For example, you have a large system that has a lot of hardware behind it and you want to be able to say you have a SAN sitting behind the hardware running Xen. You want to be able to say a guest OS can access this part of the SAN.
You want to have that same kind of separation with SELinux, but at the hypervisor level; you want to say that this operating system can access a sound card but not another part of the hardware. The same people that created SELinux at the NSA [National Security Agency] are working on similar technology for Xen, and post RHEL5 we'll begin to see the results of that work with SELinux.
How about in the general area of network management -- what's been done to reduce complexity there with RHEL5 and SELinux?
MacMillan: Policy files can get to be fairly large, reflecting the complexity of applications, and so managing them can become quite complicated. We wanted to give customers the ability to add to polices or create policies for their own applications. In the past, what happened in the policy field was that it was managed in a source form, or text format, and the user had to compile it using MAKE commands and then load those changes into the kernel.
Now Red Hat Enterprise Linux 5 and SELinux will have policy modules, which are small loadable pieces that can be distributed with an application or created by an administrator. Then, the admin creates the module and installs it on a system. This approach allows Red Hat to ship default policies for several apps that can be automated and applied right out of the box.
But when you automate all of these security processes through Red Hat, isn't there a new layer of risk introduced to the network?
MacMillan: Our approach -- and this is post RHEL5 -- will be a guided process. You will say that your application requests these access rights, where some are low risk, some are moderate risk and so on. The way this works is when you run the application, we essentially run in special mode where all access is allowed but locked and then match that up with the reference policy.
The reference policy defines the lowest policy for the system -- and this is going to be defined as a policy on all devices, files, standard file systems -- and then essentially puts them into interfaces. For example, if you want to allow a program to access DNS resolution, it wraps that up and tells you what access is allowed, and the DNS resolution may have three to four different types of access. The tool watches an application's behavior and then matches it to the appropriate reference policy interfaces. You're not completely trusting Red Hat because the policy was a community project, so interfaces are essentially vetted by the community process. All we're doing is allowing you to get matched up with those.