First SELinux impressions
SELinux introduces new layers of security, enforced by the kernel, in addition to the standard Discretionary Access Control (DAC) model that Linux users are already familiar with. The DAC model applies security based only on a user's identity and the permissions associated with files and processes. SELinux adds Mandatory Access Control (MAC) over processes and files based on a policy set by the administrator, rather than based solely on user or process identity.
SELinux also provides Type Enforcement (TE) for files and devices, otherwise known as "objects," and Role-Based Access Control for users and processes. TE in conjunction with Role-Based Access Control (RBAC) provides the ability to set policies based on the type of object, rather than its DAC permissions. The practical upshot of this is that a user or process must not only have the appropriate DAC permissions to access an object, but also must meet the RBAC requirements to access an object.
It's important to note that SELinux does not do away with the standard DAC model. For example, if a normal user attempts to execute a file owned by root with the mode 500, they will be denied the ability to do so without SELinux features coming into play. However, SELinux goes beyond that level of control. For example, an administrator can set policy that prevents a user from granting access to files to other users even if that user owns the file.
To paraphrase Spider Man's tagline, with great power comes great complexity. Getting up to speed with SELinux tools and policy will take some time. While SELinux gives an administrator a greatly enhanced security toolbox, it also complicates the job of administrating a system. The integration of SELinux adds a number of new programs and configuration files for the administrator to familiarize themselves with, as well as adding new options to familiar programs like ps and ls. It is safe to say that the syntax for SELinux's policy configuration files is less than user-friendly.
Administrators who plan to tweak the SELinux policy settings should plan to set aside a fair amount of time to learn the syntax and procedure for updating policy. To edit a system's policy requires the administrator to edit one or more of dozens of configuration files under /etc/security/selinux/src/policy, then compile and load the new policy using make.
Users should also be aware that the additional security checks involved with SELinux may come at the price of a performance impact. The Fedora SELinux FAQ notes that SELinux decreased performance by 7% for "completely untuned code" when SELinux was last tested and may have become worse due to changes made since then. Of course, a 7% drop in system performance is generally considered preferable to a 100% compromised system.
Administrators considering SELinux should note that it may limit their choice of filesystems, at least with Fedora's implementation. The popular ReiserFS in Fedora does not support file labeling, making it unsuitable for use with SELinux. This writer also found that the ability to turn enforcement on and off, using "setenforce" is quite invaluable during SELinux testing. It is possible to disable logins to a system simply by setting /etc/passwd's security context incorrectly. For those who don't want to jump into SELinux with both feet, setting the enforcement policy to "permissive" will cause the system to print warnings whenever access to an object would have been denied, but to not restrict any access beyond what the traditional discretionary controls dictate.
For the most part, the end-user experience is, with luck, largely unchanged. Though some users have reported problems with various end-user applications not working with SELinux enabled, this writer did not encounter any problems using FC2 on the desktop or at the shell for normal work.
Despite its complexity, SELinux shows a great deal of promise for improving
the overall security of Linux systems. It seems likely that the tools for
creating and customizing SELinux will improve over time and make the task
less difficult. Even at the current level of complexity, it would be well
worth an administrator's time to learn and deploy SELinux for systems that
are directly connected to the Internet or other hostile environments.
| Index entries for this article | |
|---|---|
| GuestArticles | Brockmeier, Joe |