Security

SELinux permissive domains

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:

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

    # semanage permissive -d 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:

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:

The audit2allow manpage is even more explicit:

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.

Comments (4 posted)

cups: several vulnerabilities

Comments (none posted)

dbus: denial of service

Comments (none posted)

exiv2: denial of service

Comments (none posted)

kernel: several vulnerabilities

Comments (none posted)

mon: insecure temp files

Comments (none posted)

portage: privilege escalation

Comments (none posted)

ruby: multiple vulnerabilities

Comments (none posted)

OWASP Summit set for November in Portugal

Full Story (comments: none)