LinuxCommandLibrary

sealert

Analyze SELinux denial messages

TLDR

Analyze all recent SELinux denials

$ sudo sealert [[-a|--analyze]] [/var/log/audit/audit.log]
copy

Analyze a specific alert ID from system logs
$ sudo sealert [[-l|--lookupid]] [alert_id]
copy

Display a summary of recent SELinux alerts
$ sudo sealert [[-b|--browser]]
copy

Monitor audit log in real-time for new alerts
$ sudo tail [[-f|--follow]] [/var/log/audit/audit.log] | sealert [[-l|--lookupid]] -
copy

SYNOPSIS

sealert [OPTIONS...] [FILES...]

PARAMETERS

-a, --auditlog
    Analyze audit log file(s). By default, it processes /var/log/audit/audit.log.

-l <ID>, --list=<ID>
    List alerts. If an ID is provided, it lists details for that specific alert ID.

-e <ID>, --explain=<ID>
    Explain a specific alert ID in detail, providing potential solutions.

-s <TIME>, --since=<TIME>
    Analyze denials that occurred since a specified TIME. Format usually 'YYYY-MM-DD HH:MM:SS'.

-d <DATABASE>, --database=<DATABASE>
    Specify an alternate database for alerts instead of the default.

-m <ID>, --makemodule=<ID>
    Generate a custom SELinux policy module for the specified alert ID.

-o <FILE>, --output=<FILE>
    Write the analysis output to the specified FILE instead of standard output.

-p, --permissive
    Suggest making a domain permissive instead of granting specific access. (Use with caution).

-P <PATH>, --policy-root=<PATH>
    Specify an alternate SELinux policy root directory.

-h, --help
    Show the help message and exit.

-v, --version
    Show version information and exit.

DESCRIPTION

The sealert command is a crucial tool within the SELinux ecosystem, designed to assist system administrators in understanding and resolving SELinux access denials, also known as AVCs (Access Vector Cache denials). When SELinux prevents an operation, it logs a denial message to the audit log (usually /var/log/audit/audit.log). sealert parses these often cryptic messages, correlates them with known issues and installed policy, and provides a human-readable explanation of what happened. More importantly, it often suggests specific actions to resolve the denial, such as setting a boolean, changing a file context with chcon or restorecon, or even generating a custom SELinux policy module. This significantly reduces the complexity of troubleshooting SELinux issues, making it more accessible to users who are not SELinux experts. It relies on the setroubleshoot-server service being active to perform its analysis.

CAVEATS

sealert relies on the setroubleshoot-server service being installed and running to analyze audit logs and provide suggestions. If this service is not active, sealert may not be able to retrieve or explain alerts. The suggested solutions, especially those involving generating policy modules, should be reviewed carefully by an administrator to ensure they align with the system's security requirements. Blindly applying suggested changes can weaken the system's security posture. Analyzing large audit logs without filters can generate extensive output.

ANALYZING SPECIFIC DENIALS

To analyze a specific SELinux denial, you often first need to identify its unique ID. This can be done by running sealert -a /var/log/audit/audit.log and looking for the "ID" field in the output. Once you have the ID, you can use sealert -l or sealert -e to get detailed information and solution suggestions for that particular event.

GENERATING LOCAL POLICY MODULES

For complex or application-specific denials that cannot be resolved by existing booleans or file context changes, sealert -m can generate a local policy module (.te and .if files) that, when compiled and loaded, will permit the specific action that was denied. This provides a precise way to customize policy without disabling SELinux or making overly broad changes.

HISTORY

The sealert command is part of the setroubleshoot project, which was developed to address the steep learning curve associated with SELinux by providing automated analysis and user-friendly explanations for SELinux denials. Its development aimed to make SELinux more approachable for system administrators by translating raw audit log messages into actionable advice, thereby improving the overall manageability of SELinux-enabled systems. It evolved to become an essential tool for diagnosing and resolving SELinux-related issues on Red Hat-based distributions and other systems employing the setroubleshoot framework.

SEE ALSO

auditctl(8), auditd(8), setroubleshoot(8), semanage(8), restorecon(8), chcon(1), setsebool(8)

Copied to clipboard