How SELinux Blocks Unrar File Extraction

When the unrar utility attempts to extract an archive into a target location restricted by Security-Enhanced Linux (SELinux), the operating system's kernel enforces Mandatory Access Control (MAC) to block the unauthorized write or create operations. This results in standard "Permission denied" terminal errors, incomplete or missing extracted files, and logged Access Vector Cache (AVC) denial messages within system audit logs, all while leaving the source RAR archive completely unmodified.

The Enforcement Mechanism

SELinux operates at the Linux kernel level, evaluating permissions beyond standard Discretionary Access Control (DAC) file permissions (such as read, write, and execute bits). Even if the user executing unrar has standard write privileges or root access, SELinux evaluates the security context (user, role, type, and level) of both the unrar process and the destination directory.

If the security policy does not explicitly permit the domain of the running process to write to, create files in, or relabel files within the target context, the kernel immediately halts the system call.

Manifestation in unrar

When a restriction occurs during extraction, unrar typically demonstrates the following behaviors:

  • Creation Failure: If unrar cannot create the target file or subdirectory, it outputs an error message such as Cannot create <filename> followed by Permission denied.
  • Extraction Halts or Skips: Depending on the flags passed to unrar (such as -kb to keep broken extracted files), the process will either abort immediately or skip the restricted file and attempt to process remaining items in the archive.
  • Partial Files: If the file creation call is allowed but subsequent writing or attribute adjustments are restricted, an empty or truncated file may remain in the destination directory.

Audit Logging (AVC Denials)

Whenever SELinux denies an action initiated by unrar, it logs an AVC denial message. On most enterprise Linux distributions (such as RHEL, CentOS, Rocky Linux, or Fedora), this event is recorded in /var/log/audit/audit.log.

A typical denial entry includes:

  • scontext (Source Context): The SELinux label under which unrar is running (e.g., unconfined_u:unconfined_r:unconfined_t:s0).
  • tcontext (Target Context): The label of the destination directory or existing target file (e.g., system_u:object_r:httpd_sys_content_t:s0).
  • tclass (Target Class): The resource type being accessed, typically file or dir.
  • comm: The command name, showing unrar.
  • denied: The specific action prevented, such as write, create, or setattr.

Enforcing Mode vs. Permissive Mode

The outcome of the extraction depends on the active SELinux operating mode:

  • Enforcing Mode: The default operational mode where policy rules are strictly applied. The extraction is physically blocked, and an AVC denial is generated.
  • Permissive Mode: SELinux does not block the extraction. unrar successfully writes the files to disk, but the kernel still records the AVC denial in the audit log to warn administrators that the action violated active policy rules.

Resolving Extraction Failures

To address these restrictions without globally disabling system security:

  1. Verify the Denial: Use ausearch -m avc -ts recent or journalctl -t setroubleshoot to confirm that SELinux caused the failure.
  2. Inspect Contexts: Check the target path's context using ls -dZ /path/to/destination.
  3. Reset Contexts: If the target directory was mislabeled, restore the correct default security context using restorecon -Rv /path/to/destination.
  4. Adjust Booleans or Policies: If extracting to shared or service-specific locations (such as web server roots or network shares), enable the relevant SELinux boolean or generate a custom policy module using audit2allow.