SELinux with omarine policy: An in-depth look at the security policy – secure program with its own domain: Part 9


Using audit2allow to generate rules

audit2allow is a utility that generates rules from logs of denied operations. It suggests rules for those operations  to succeed. To see the suggested rules, run the following command, as the root user:

audit2allow -l -a

This utility needs to be used with caution because it only provides rules about denied operations without knowing which denied operations are the intention of the policy to ensure security. So avoid using audit2allow blindly because it might cause a security threat.
For example, we already know that only the domain myapp_se_t can read its temporary file with the type myapp_se_tmp_t, and the domain user staff_t cannot directly read the file. If you do that, the operation will be denied. This is the intention of the policy. But if you run audit2allow -l -a it will suggest a rule that allows staff_t to read that temporary file

If that rule is inserted into the policy, the myapp_se program will become less secure than its design purpose.

audit2allow and constraint

The audit2allow utility only generates rules, it has no effect when constraint is violated. We recall that the constraint condition was added to the base module. When root reads the temporary file of the myapp_se program, the operation is denied. See the output of audit2allow:

In this case the rule that audit2allow suggested is useless.

Because caution is needed when using audit2allow even though it is a popular support tool, I leave it in the last part of this series. You should only use audit2allow when you have created the rules manually, like practicing through the myapp and myapp_se modules.

Currently unrated


There are currently no comments

New Comment


required (not published)



What is 6 × 5?