Most implementations of SELinux include Audit2allow, a tool that can help you create or customize a domain. Some fledgling SELinux administrators use Audit2allow indiscriminately, rendering their system less secure. One technical reviewer of this book terms Audit2allow “evil,” not so much because of problems with the tool itself as because of the way it’s often misused. In this section, I’ll explain how to use Audit2allow more carefully, so that you can avoid this pitfall.
Audit2allow is a Perl script that processes recent AVC messages. It
analyzes the messages it finds and prints
rules that—if added to the current policy—would authorize
the denied operations. Hence, you can go badly wrong by blindly
accepting its recommendations. For instance, perhaps someone has
attempted a prohibited operation. Adding the rules generated by
Audit2allow will authorize the prohibited operation, but may also
compromise system security. Another more subtle source of problems is
that Audit2allow takes the current type architecture and file labels
as given. Often it’s appropriate—or even
necessary—to create a new domain that encapsulates a program or
operation, as I did in the preceding section. But Audit2allow
provides no help in doing so.
Audit2allow is less than perfect in other ways. For instance, it is
sometimes blind to prohibited operations. This can occur if the
operation is covered by a
dontaudit rule. It can also occur if AVC message caching has caused one or more messages ...