audit2allow

Show all generated messages in audit and message logs

$ audit2allow [[-a|--all]]

$ audit2allow [[-b|--boot]]

$ audit2allow [[-e|--explain]]

$ audit2allow [[-v|--verbose]]

$ audit2allow [[-R|--reference]]

$ audit2allow [[-p|--policy]] [path/to/policyfile]

$ audit2allow [[-t|--type]] [type_regex]

$ audit2allow [[-h|--help]]

audit2allow [OPTIONS] [FILENAME...]
Example usage:
audit2allow -a
audit2allow -a -M mycustommodule
audit2allow -i /path/to/audit.log

-a
    Reads audit messages from the active system audit log (/var/log/audit/audit.log).

-w
    Writes the generated policy module to the current directory after compilation. Requires the -M option.

-M
    Specifies the name for the new SELinux policy module. Used in conjunction with -w to create a loadable module.

-l
    Lists the rules that are currently allowed by the existing SELinux policy, useful for debugging or policy analysis.

-R
    Disables reading existing SELinux rules from the current policy, treating all denials as new. Useful for a fresh start.

-D
    Generates rules that include `dontaudit` or `allow` statements based on specific interface calls, often for targeted debugging.

-i
    Reads audit messages from the specified input file instead of standard input or the default audit log.

-o
    Writes the generated SELinux type enforcement rules to the specified output file instead of standard output.

-r
    Generates rules specifically for the `root` SELinux context (`root_t`), often used for system-level issues.

-s
    Generates rules specifically for the `sysadm_t` SELinux context, relevant for administrative tasks.

-t
    Generates rules specifically for the `unconfined_t` SELinux context, for processes running without specific confinement.

-u
    Generates rules specifically for the `user_t` SELinux context, for user-initiated processes.

audit2allow is a utility that assists System Administrators in creating custom SELinux (Security-Enhanced Linux) policy rules. Its primary function is to parse AVC (Access Vector Cache) denial messages found in the system's audit logs, typically located at /var/log/audit/audit.log. When an application or process is denied access by SELinux due to a missing policy rule, an AVC denial is logged. audit2allow analyzes these denials and suggests corresponding SELinux allow rules that, if added to the policy, would permit the previously denied operation.

It can output these suggested rules to standard output, a file, or directly compile them into a local policy module (`.pp` file) which can then be loaded into the kernel. While a powerful tool for simplifying policy development, it requires careful review of the generated rules to prevent creating overly permissive or insecure policies, as it only addresses specific denials and might not capture the full context of the required permissions. It's often used as a first step in debugging SELinux issues or developing new custom policies for applications.

audit2allow is a powerful debugging and policy development tool, but it should be used with caution.
Overly Permissive Policies: Automatically generating policy rules from audit logs can lead to overly permissive policies. It addresses only the specific denial that occurred, potentially granting broader access than strictly necessary. Always review the generated rules carefully before incorporating them into your SELinux policy.
Context Dependency: The generated rules are based on the immediate context of the denial. If the underlying issue is incorrect file contexts or labeling, `audit2allow` might generate rules that workaround the symptom rather than address the root cause.
Incremental Usage: It is best used iteratively. Apply a small set of generated rules, test, and then repeat the process if further denials occur, rather than trying to resolve all issues at once.
Not a Replacement for Understanding: It simplifies policy creation but doesn't replace the need for understanding SELinux concepts and best practices for secure policy design.

The most common workflow for using `audit2allow` involves:
1. Reproducing the issue that causes SELinux denials.
2. Running `audit2allow -a -M mycustommodule` to generate a Type Enforcement (`.te`) file and compile it into a policy package (`.pp`). For instance, `audit2allow -a -M myapp_policy`.
3. Reviewing the generated `myapp_policy.te` file for any overly broad or unnecessary rules.
4. Loading the compiled policy module into the kernel using `semodule -i myapp_policy.pp`.
5. Testing if the issue is resolved. If not, repeating the process.
6. Optionally, removing the module with `semodule -r myapp_policy` if the changes are deemed incorrect or should be temporary.

When not using the `-w` option to compile a module, `audit2allow` outputs SELinux Type Enforcement (`.te`) language rules. These rules typically define `allow` statements, specifying source and target types, object classes, and permissions. For example:
`allow httpd_t self: capability { chown dac_override };`
`allow httpd_t var_log_t: file { append open };`
This output is human-readable and can be directly used in a `.te` file for custom policy development.

audit2allow is a core utility within the policycoreutils package, which provides essential user-space tools for managing SELinux. Its development has been integral to making SELinux more manageable for system administrators. As SELinux gained wider adoption, the need for tools to simplify the creation and debugging of custom policies became apparent. `audit2allow` emerged as a pragmatic solution to translate cryptic AVC denials into actionable policy rules. It has continually evolved to include more options and intelligence for generating policy, although its fundamental purpose remains assisting in the interpretation of audit logs to address permission issues. Its inclusion in major Linux distributions reflects its importance in the SELinux ecosystem.

semanage(8), sealert(8), restorecon(8), setenforce(8), chcon(1), auditd(8), ausearch(8), auditctl(8), semodule(8)