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
audit2allow -l -a
Share on Twitter
Share on Facebook
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
Can't see mail in Inbox? Check your Spam folder.