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
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.
to post comments)