SELinux Contexts: Labels, Booleans, and Daily Operations

Most SELinux administration work is label and context work. Once you know how to inspect labels, restore expected types, and adjust booleans intentionally, many denials become straightforward to resolve.

Table of Contents

This post focuses on practical commands you will use regularly when managing SELinux systems.

Context Basics

Daily Operations

Series Navigation

Context format and what matters most

A SELinux context is usually written as user:role:type:level. In most operations and troubleshooting, the type field drives the outcome you care about.

For example:

system_u:object_r:httpd_sys_content_t:s0
system_u:system_r:httpd_t:s0

The first label is a file object type and the second is a process domain. Policy decides what httpd_t can do with httpd_sys_content_t.

Inspect labels on files and processes

Use these commands early in troubleshooting to compare expected and actual contexts.

ls -Z /var/www/html
ps -eZ | head -20
id -Z
stat -Z /var/www/html/index.html

Each command gives a different view:

  • ls -Z shows file and directory labels in path listings
  • ps -eZ shows process domains for running services
  • id -Z shows your current user context in the active session
  • stat -Z gives precise context for one object

How process and file types interact

SELinux policy does not only care about user identity. It checks whether a process domain is allowed to perform a specific action on an object type.

A common web example:

  • httpd_t reading httpd_sys_content_t is normally allowed
  • httpd_t writing httpd_sys_content_t is typically denied
  • httpd_t writing httpd_sys_rw_content_t can be allowed by policy

This model is why relabeling content correctly usually matters more than chmod changes.

chcon vs restorecon and when each fits

chcon directly modifies an object label, but that change can be overwritten by future relabel operations. restorecon applies labels based on policy rules and local semanage fcontext mappings.

Use this pattern for durable fixes:

sudo restorecon -Rv /var/www/html

Use chcon only for short tests when you intentionally want a temporary change.

Preview persistent labeling with semanage fcontext

Persistent labeling rules belong in SELinux policy mappings. semanage fcontext lets you define expected types for paths, then restorecon applies them.

sudo semanage fcontext -l | head -20
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/myapp(/.*)?'
sudo restorecon -Rv /srv/myapp

Post 4 covers this workflow in depth, including regex scope and rule maintenance.

Tune booleans without weakening policy

Booleans are policy toggles created by policy authors for common runtime choices. They are often a cleaner fix than adding custom allow rules.

getsebool -a | grep httpd
sudo setsebool httpd_can_network_connect on
sudo setsebool -P httpd_can_network_connect on

Guidance for boolean use:

  • Use setsebool without -P to validate behavior first
  • Add -P only after confirming the change should persist across reboot
  • Enable only the boolean needed for the target behavior

Use runcon for one-off tests

runcon starts a command under a selected context, which can help validate whether a domain-specific restriction is the source of a denial.

runcon -t httpd_t -- cat /srv/myapp/config.yml

Treat runcon as a diagnostic tool, not a replacement for correct service configuration.

Container relabeling with :Z and :z

For container bind mounts, relabeling options can prevent confusing denials when container processes access host content.

podman run --rm -v /srv/appdata:/data:Z registry.example.com/myimage:latest
podman run --rm -v /srv/shared:/data:z registry.example.com/myimage:latest
  • Use :Z for private content used by one container workload
  • Use :z for shared content used by multiple container workloads

Series navigation

With contexts and booleans in place, the next step is reading AVC denials and applying targeted fixes with confidence.

Next in this series

Next, we break down AVC denials with ausearch, audit2why, and a repeatable troubleshooting flow that avoids unsafe broad exceptions.