SELinux permissive domains [LWN.net]

By Jake Edge
October 15, 2008

Readers of this page—along with the kernel page—will not find it surprising that SELinux is a complex beast. It is, however, the dominant security framework for Linux, pushed hard by Red Hat, but also being adopted, slowly, by SUSE, Ubuntu, and others. Over the years, through lots of hard work, it has become somewhat less complex, at least for administrators; a new feature, called permissive domains will help further ease the administration of SELinux-enabled systems.

These days, SELinux has two modes, the aptly named enforcing and permissive modes. When in enforcing mode, SELinux will not allow operations that are not permitted by the policy, whereas in permissive mode, a violation is just logged and the operation is allowed to continue. Administrators trying to track down an SELinux problem with an application—whether a real security issue or just a problem with the policy—can put the system into permissive mode, then study the logs to determine what policies are being violated. Or they can use audit2allow to make those policy changes for them.

Until permissive domains, though, the choice between permissive and enforcing was binary for the entire system. By putting a system into permissive mode, various attacks that SELinux might normally stop on other applications would instead just be logged. With permissive domains, a single process, or group of related processes, can be marked as permissive, while the rest of the system stays in enforcing mode.

Red Hat SELinux hacker Dan Walsh, describes permissive domains on his blog. One of the motivations is to help third-party software developers feel more comfortable about shipping SELinux policy with their application:

Another problem SELinux has is that third party software companies want to ship with SELinux policy for their software but do not trust that they have tested it well enough to run their confined applications in enforcing mode. I have talked to developers of stock market software that wanted to write policy for an application, distribute it to a live environment of several hundred machines, and then gather the AVCs as they happen, using this information to fine-tune their policy. After a long period of time, where they saw no AVCs, they might be willing to put their policy in enforcing mode. In RHEL5 they need to put the entire machine in permissive mode, but permissive domains solve this problem.

Permissive domains are available in recently updated Fedora 9 systems and will come standard with Fedora 10. As Walsh shows, enabling permissive mode for a domain is trivial:

    # semanage permissive -a httpd_sys_script_t

which would put all CGI scripts into permissive mode. And:

    # semanage permissive -d httpd_sys_script_t

to remove permissive mode for the CGI script domain (httpd_sys_script_t).

This is definitely a nice step forward for assisting with policy development, but there is still a lingering problem with the recommended way to generate SELinux policies. Walsh describes how that is done:

Finally, when someone wants to write policy for a new confined domain, we tell the policy writer to build a minimal policy using tools like system-config-selinux. Then we advise them to put the machine in permissive mode, run the confined application, collect the AVC messages, use audit2allow to generate new policy, and try again. Lather, rinse, repeat. This puts the entire machine at risk, since it is no longer protected by SELinux. With permissive domains, you can mark the new domain as permissive and avoid putting the machine at risk.

The problem, of course, is that blindly using audit2allow is extremely dangerous. It assumes that the application has no security problems, that all of its accesses should be permitted—if that can be assumed, what is SELinux for? By taking all of the violations and turning them into policy changes, the application, rather than the policy developer, decides on the access it requires. Using audit2allow correctly is much more complex, requiring a good understanding of SELinux and the existing policies and domains.

To be fair to Walsh, in a related post, he does warn:

Whenever you generate policy in this way you should really examine the te file for what rules audit2allow has generated and try [to] make sure they make sense, and don't open a security [hole]. It is always good to ask if the policy is good on a list like fedora-selinux. If you believe this is a bug in policy, please open a bugzilla. Then we can fix the policy for others.

The audit2allow manpage is even more explicit:

Care must be exercised while acting on the output of this utility to ensure that the operations being permitted do not pose a security threat. Often it is better to define new domains and/or types, or make other structural changes to narrowly allow an optimal set of operations to succeed, as opposed to blindly implementing the sometimes broad changes recommended by this utility. Certain permission denials are not fatal to the application, in which case it may be preferable to simply suppress logging of the denial via a dontaudit rule rather than an allow rule.

Using audit2allow is, unfortunately, the way that most SELinux policy is developed. There aren't enough SELinux experts—there may never be enough—to actually look at the code for applications and determine a priori what the policy should look like. So, testing applications by running them to determine what permissions they require is the only sane way to do it, error-prone though it may be.

(Log in to post comments)