Running SELinux in Enforcing Mode: Troubleshooting and Writing Custom Policy

The single most common SELinux “fix” on the internet is setenforce 0, and it is almost always wrong. SELinux is not a misbehaving guest on your server; it is a mandatory access control (MAC) system that contains a compromised daemon to the handful of operations that daemon legitimately needs — so that a remote-code-execution bug in your web server cannot read /etc/shadow, write cron jobs, or pivot to the database socket. When a service fails and SELinux is involved, the kernel has already told you exactly what it refused and why. Disabling it throws that diagnostic away and leaves you with an unconfined, un-auditable process running with the full discretionary permissions of its UID.

This is the operator’s playbook for running SELinux enforcing in production and never reaching for setenforce 0 under pressure. You will learn to read an AVC (Access Vector Cache) denial field by field from /var/log/audit/audit.log, to triage the three fixable causes that account for the overwhelming majority of denials — a wrong file context, an unregistered port, or a boolean that is off — with semanage, restorecon and setsebool -P, and only then, when a service genuinely has no upstream policy, to author a clean, minimal custom policy module from .te, .if and .fc sources using reference-policy interfaces rather than a raw audit2allow dump. The centerpiece is a symptom-to-fix denial playbook you keep open at 02:00 when a daemon won’t start and journalctl is being unhelpful.

By the end you will treat a denial the way a senior engineer does: as data, not an obstacle. When httpd returns 503, when a container can’t bind its port, when a moved file 404s, when a third-party agent silently runs unconfined in init_t, you will know within ninety seconds whether you are looking at a mislabelled file, a missing port registration, an off boolean, or a real policy gap that warrants a module — and you will fix the right one, persistently, without weakening the machine.

What problem this solves

SELinux failures are maddening precisely because the surface symptom lies. A daemon exits with a generic error, systemctl status shows code=exited status=1 with no useful detail, and the application’s own logs say “permission denied” on a path the Unix mode bits clearly allow. The ls -l output shows rw-r--r-- root root on a file the root process cannot read — because the type label is wrong and discretionary permissions never entered into it. Nothing in the ordinary Linux toolchain (ls -l, strace at a glance, the app log) points at SELinux, so engineers who do not know to check ausearch conclude the platform is broken and disable the one control that was doing its job.

What breaks without this knowledge is worse than a single outage. An on-call engineer runs setenforce 0, the daemon starts, the incident closes, and the machine now runs permissive until the next reboot re-reads /etc/selinux/config — or, if someone “made it permanent,” forever. A compromised nginx on that box can now do everything nginx’s UID can do: read every world-readable secret, connect anywhere, write to any directory the mode bits allow. In a regulated environment (PCI-DSS, FedRAMP, CIS Level 2, many DoD STIGs) enforcing SELinux is a hard control; setenforce 0 is an audit finding on the spot. Meanwhile the actual cause — a file relabelled by mv, a service moved to a non-standard port, a boolean nobody flipped — sat there, perfectly diagnosable, ignored.

Who hits this: anyone running RHEL, Rocky, AlmaLinux, CentOS Stream, Fedora, or Oracle Linux with the default targeted policy; anyone shipping a third-party or in-house daemon that has no upstream policy module; anyone moving web or app content between directories; anyone running containers under Podman or CRI-O where MCS categories isolate each container; and anyone who has ever “fixed” an SELinux problem with chcon in a config-management role and been bitten weeks later by a routine relabel that silently reverted it. The fix is almost never to weaken SELinux — it is to read the denial, apply the right tool, and (when warranted) write twenty lines of policy that give the service its own confined domain.

To frame the whole field before the deep dive, here is every denial class this article covers, the question it forces, and the first place to look:

Learning objectives

By the end of this article you can:

• Explain type enforcement precisely: the four-field security context (user:role:type:level), why the type does the work, how files get types and processes get domains, and how a type_transition confines a daemon automatically.
• Read a raw AVC denial from audit.log field by field — scontext, tcontext, tclass, the permission, permissive=, comm, pid — and turn it into an exact remediation.
• Drive the audit toolchain fluently: ausearch to find denials, audit2why to explain them, sealert/setroubleshoot for guided remedies, and audit2allow to scaffold (never blindly ship) rules.
• Triage the three fixable causes in the right order — context → port → boolean — using restorecon, semanage fcontext, semanage port and setsebool -P, and know when each is authoritative.
• Distinguish enforcing / permissive / disabled modes and per-domain permissive (semanage permissive), and know why you never edit /etc/selinux/config to fix a symptom.
• Distinguish confined vs unconfined domains, diagnose why a third-party daemon runs unconfined in init_t, and give it a real domain.
• Author a clean, minimal custom policy module — .te, .if, .fc — that declares private types, uses reference-policy interfaces discovered with sepolicy, applies file transitions, and builds reproducibly with the devel Makefile; then roll it out safely via per-domain permissive before flipping to enforcing.
• Reason about MCS/MLS categories and container-selinux — why containers get s0:c<n>,c<m> labels, and how :z/:Z volume relabelling works.

Prerequisites & where this fits

You should be comfortable on an enterprise Linux host: systemd service management (systemctl, journalctl), the Unix permission model (owners, groups, mode bits — SELinux is checked after these pass), reading /var/log, and installing packages with dnf. You should know what a daemon is, what a TCP port is, and roughly how nginx/httpd/postgresql are laid out on disk. No prior SELinux knowledge is assumed, but this is an Expert-level treatment: it moves fast through the model and spends its length on troubleshooting and policy authoring.

This sits in the Linux security hardening track. SELinux is one MAC implementation; the sibling article on Authoring AppArmor Profiles: Confining Services on Ubuntu and Debian covers the path-based alternative you meet on Ubuntu/Debian, and reading both makes the type-enforcement-versus-path-based trade-off concrete. Denials land in the audit subsystem, so it pairs tightly with Building a Linux Audit Trail with auditd and eBPF Runtime Visibility — audit.log is the same log both articles read. Because systemd is what transitions a daemon into its domain, Mastering systemd: Units, Timers, Resource Control, and Service Hardening is upstream of the confined-vs-unconfined discussion. And the container isolation section connects directly to Running Rootless Containers in Production with Podman and Quadlet, where MCS categories keep containers apart.

A quick map of who confirms what during an SELinux incident, so you reach for the right tool fast:

Core concepts

Five mental models make every later diagnosis obvious.

SELinux is default-deny type enforcement, checked after DAC. Traditional Unix permission (mode bits, owners, groups) is discretionary access control (DAC) — the file’s owner decides who may read it. SELinux adds mandatory access control on top: even if DAC allows an operation, the kernel consults the policy, and if no rule explicitly permits it, the operation is denied. Crucially, DAC is checked first — a denial you see in audit.log means DAC already passed and SELinux is the one saying no. Every process and object carries a security context of four fields — user:role:type:level — and the field that does the enforcement work is the type. The policy is one enormous allowlist of rules of the form “the domain (a process type) X may perform action Y on objects of type Z”. Everything not written is refused.

Files have types; processes have domains; a transition ties them together. A file’s type — sometimes called its label or context — comes from policy rules keyed on its path: /var/www/html is httpd_sys_content_t, /etc/shadow is shadow_t. That label lives in the security.selinux extended attribute on the inode, so it travels with the file on the same filesystem and is why mv (which preserves the xattr) behaves differently from cp (which lets the destination policy assign a fresh one). A process type is called a domain: httpd_t, sshd_t, postgresql_t. When systemd (itself running in init_t) executes a binary labelled httpd_exec_t, the policy contains a type_transition rule that moves the new process into httpd_t. This is why a confined daemon becomes confined automatically — the transition is declared in policy, not configured by you, and it is the single mechanism you must reproduce when you confine your own daemon.

A denial names the actor, the target, and the operation — that is the whole skill. When the kernel refuses, it emits an AVC record to the audit subsystem. Read three fields and you know the fix: scontext is the source domain (the actor — who tried), tcontext is the target context (what it tried to touch), and tclass plus the bracketed permission ({ read }, { name_bind }, { name_connect }) is the operation. A tcontext of default_t where you expected httpd_sys_content_t is a labelling problem. A tclass=tcp_socket with { name_bind } and a port in the record is a port-registration problem. A denial that a boolean would have permitted is a boolean problem. The permission and the target type route you to one of exactly three fixes before you ever consider writing policy.

Modes are global, but permissiveness can be per-domain. SELinux runs in one of three global modes: enforcing (denials block and log), permissive (denials log but do not block — invaluable for discovery), or disabled (the LSM is off; no labels maintained — avoid, and note that going from disabled back to enforcing needs a full relabel). But the sharp tool is per-domain permissive: semanage permissive -a <domain> makes a single type run permissive while the entire rest of the system stays enforcing. That is how you safely bring up a new confined daemon in production — the new domain logs what it needs without blocking, everything else stays protected — then you harvest the denials, fold them into policy, and remove the exception.

Most denials are not policy bugs — they are one of three fixable conditions. Before you ever write a module, three cheap checks resolve the overwhelming majority of tickets: the file is in the wrong place or was moved (fix with restorecon), the service listens on a non-standard port the policy doesn’t know about (fix with semanage port), or a boolean that gates the behaviour is off (fix with setsebool -P). The triage order is context, then port, then boolean. Only when all three are correct — the labels match, the port is registered, the relevant booleans are on — do you have a genuine policy gap that a custom module addresses.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the model side by side:

To ground the abstractions, here are the confined domains you meet most on a real server, the binary that enters each, and the private types they own — this is the shape your custom module should imitate:

How type enforcement actually works

Start with the context. Inspect any process or object with the -Z flag, which nearly every core utility understands, and you will see the four fields:

id -Z
# unconfined_u:unconfined_r:unconfined_t:s0

ps -eZ | grep -E 'httpd|nginx'
# system_u:system_r:httpd_t:s0   1234 ?  00:00:01 httpd

ls -Z /var/www/html/index.html
# unconfined_u:object_r:httpd_sys_content_t:s0 index.html

ss -ltnpZ | grep :443
# LISTEN 0 511 *:443 users:(("httpd",pid=1234)) ... system_u:system_r:httpd_t:s0

The four fields, and how much each matters in the targeted policy that every mainstream distribution ships by default:

In targeted policy — the default on RHEL, Rocky, Alma, Fedora, Oracle Linux — the first two fields are largely fixed (system_u/system_r for system processes, object_r for files) and the type is where all the action is. Do not be distracted by user and role when troubleshooting a standard box; the denial you are chasing is almost always about the type.

The -Z flag is your window into contexts, and nearly every core utility accepts it. Commit these to reflex — you run them constantly during triage:

Labelling: how a file gets its type

A file’s type is not stored in the policy — it is stored on the file, in the security.selinux xattr — but where it comes from is a policy rule keyed on the path. The semanage fcontext database maps path regexes to types; restorecon reads that database and stamps the correct label onto the inode. This split is the source of the single most common class of bug, so hold it clearly:

The workflow that makes labels correct forever: register the path with semanage fcontext -a, then apply with restorecon. chcon is for a ten-second experiment and nothing else, because a routine restorecon -R / or an /.autorelabel boot will silently undo it.

Domain transition: how a process gets confined

When you start systemctl start httpd, the sequence is: systemd runs in init_t; it execs /usr/sbin/httpd, which policy has labelled httpd_exec_t; a type_transition init_t httpd_exec_t : process httpd_t; rule fires; the new process lands in httpd_t. Three ingredients must all be present — the binary’s *_exec_t label, an entrypoint relationship (httpd_exec_t is declared the entrypoint of httpd_t), and the transition rule. Break any one and the daemon does not enter its domain:

Confirm the outcome in one command — this is the first thing to run when a daemon misbehaves:

ps -eZ | grep my-daemon
# GOOD:  system_u:system_r:my_daemon_t:s0   ... my-daemon
# TRAP:  system_u:system_r:init_t:s0        ... my-daemon   <- unconfined

If your daemon shows init_t or unconfined_service_t, it has no real confinement and no policy module — that is your starting point for the authoring sections below.

Confirm your enforcing state first

Never begin troubleshooting without knowing the mode. A “denial” you cannot reproduce is often because the box is already permissive:

getenforce          # Enforcing | Permissive | Disabled
sestatus            # full status: policy name, store, mode, MLS/MCS status

sestatus output on a healthy targeted box reads SELinux status: enabled, Current mode: enforcing, Loaded policy name: targeted. If Current mode says permissive you are seeing logged-not-blocked denials and the app is not actually being stopped — a common source of “it works on staging” confusion.

Modes: enforcing, permissive, disabled — and per-domain permissive

The global mode is set at runtime with setenforce and at boot in /etc/selinux/config. Understand every combination and, critically, why disabling is the one you almost never want:

Runtime toggles and the persistent setting:

setenforce 0        # Permissive  (momentary diagnostic ONLY — set it straight back)
setenforce 1        # Enforcing
getenforce          # confirm

# Persistent mode lives here — set enforcing and LEAVE IT:
grep '^SELINUX=' /etc/selinux/config     # SELINUX=enforcing

The rule that saves you an audit finding: do not edit /etc/selinux/config to “fix” a problem. Keep SELINUX=enforcing permanently. setenforce 0 is acceptable for a few seconds to prove SELinux is the cause of a symptom (if it starts working permissive, SELinux is involved), but you flip it straight back and then diagnose properly. The reason disabling is genuinely dangerous, not merely frowned upon: while disabled, new and modified files never get labelled, so the on-disk labels drift out of sync with reality; when you eventually re-enable, everything is mislabelled and you must trigger a full filesystem relabel (fixfiles onboot or touch /.autorelabel; reboot), which on a large host is a long maintenance window.

Per-domain permissive is the professional’s tool and deserves emphasis. It lets you observe exactly what one new type needs without exposing the machine:

semanage permissive -a my_daemon_t     # ONLY my_daemon_t runs permissive
semanage permissive -l                 # list current permissive domains
semanage permissive -d my_daemon_t     # remove the exception → back to enforcing for it

There is also a related distinction worth knowing: a type can be declared permissive in a module (permissive my_daemon_t; in a .te) — the same effect, shipped as policy. Prefer semanage permissive for temporary bring-up because it is trivially reversible without a rebuild.

Reading AVC denials — the core skill

When the kernel refuses an action it writes an AVC (and sometimes USER_AVC) record to /var/log/audit/audit.log. Do not grep that file raw. Use ausearch, which parses records, resolves timestamps from epoch, and lets you filter by message type, time, and process. audit.log is line-noise; ausearch is readable:

ausearch -m AVC,USER_AVC -ts recent            # AVCs in the last ~10 minutes
ausearch -m AVC -ts today | tail -n 40         # today's denials
ausearch -m AVC -c httpd -ts recent            # only comm=httpd
ausearch -m AVC -su httpd_t -ts today          # only scontext user/type httpd_t
ausearch -m AVC --start 09:00 --end 09:30      # a specific window

The ausearch flags you will actually use, so you scope a denial fast instead of scrolling audit.log:

A raw denial — the thing you are learning to read:

type=AVC msg=audit(1715520000.123:456): avc:  denied  { name_connect } for
  pid=2310 comm="httpd" dest=8080 scontext=system_u:system_r:httpd_t:s0
  tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket permissive=0

Read it field by field. This table is the diagnostic method — internalise it and you can decode any denial:

The permissive= field is the one people miss. permissive=1 means the record was logged but the operation was allowed — you are on a permissive box or a per-domain-permissive type, and this “denial” did not actually stop anything. permissive=0 is a real block. When someone says “SELinux is denying X but disabling it doesn’t help,” check whether they were reading permissive=1 records the whole time.

Common permissions and the object classes they appear on, so a bracketed verb immediately suggests a category of fix:

Explaining a denial: audit2why, sealert, and setroubleshoot

ausearch shows you the denial; audit2why tells you why it happened and often what class of fix it needs — wrong label, missing boolean, or a genuine gap:

ausearch -m AVC -ts recent | audit2why
# ... prints, per denial, one of:
#   "Was caused by:  Missing type enforcement (TE) allow rule."      -> real gap
#   "... one of the following booleans: httpd_can_network_connect"   -> flip a boolean
#   "... you may need to relabel ... restorecon -R -v /path"          -> a labelling fix

For a plain-English explanation with a suggested exact command, install setroubleshoot-server and use sealert. It correlates related denials and frequently names the precise setsebool or semanage line to run — and it is what fires the desktop/journal “SELinux is preventing…” notifications:

dnf install -y setroubleshoot-server
sealert -a /var/log/audit/audit.log          # analyse the whole log
journalctl -t setroubleshoot --since "10 min ago"   # the notifications it raised

The three-tool division of labour, so you pick the right one:

The dontaudit trap: when a denial is invisible

Some denials are noisy but harmless — a daemon probing for a capability it does not really need, a library stat-ing paths it may not read. Policy authors silence these with dontaudit rules so they never reach the log. That is usually a kindness, but it becomes a trap when a service genuinely misbehaves and you see nothing in ausearch. If a daemon fails and the audit log is silent, temporarily disable all dontaudit rules, reproduce, and re-enable:

semodule -DB          # -D disable dontaudit, -B rebuild/reload the policy
# ... reproduce the failure now; the previously-silenced denials will appear ...
ausearch -m AVC -ts recent
semodule -B           # rebuild WITHOUT -D → dontaudit rules back on (ALWAYS do this)

Leaving dontaudit disabled floods the log with harmless noise and can hide real signal, so the semodule -B at the end is not optional. This is the answer to “SELinux is definitely the problem but there are no denials.”

Fix the common cases first — context, then port, then boolean

The overwhelming majority of denials are one of three fixable conditions. Rule them out in this order before you consider a module; a custom policy for what is actually a mislabelled file is a self-inflicted maintenance burden.

Cause 1 — Wrong file context (the number-one cause)

You put content where policy does not expect it, or — far more often — you mvd a file (which preserves its old label) instead of cping it. The denial shows a tcontext type that does not match what the domain wants: default_t or user_home_t where httpd_sys_content_t belongs.

Confirm what the label is versus what it should be, without changing anything:

ls -Z /var/www/html/index.html
# unconfined_u:object_r:user_home_t:s0 index.html    <- wrong; came from a home dir via mv

restorecon -nv /var/www/html/index.html
# would relabel .../index.html from user_home_t to httpd_sys_content_t   <- -n = dry run

Fix. If the path is already covered by policy (as /var/www/html is), just restore it:

restorecon -Rv /var/www/html          # -R recursive, -v verbose (shows every change)

If the path is not a standard one — say you serve content from /srv/webdata — register a rule first, then restore. This is what makes the label authoritative forever:

semanage fcontext -a -t httpd_sys_content_t '/srv/webdata(/.*)?'   # add the rule
restorecon -Rv /srv/webdata                                        # apply it
semanage fcontext -l | grep webdata                               # verify the rule exists

chcon exists and works, but reserve it for a ten-second experiment. Putting chcon in Ansible/Puppet/a systemd ExecStartPre is a latent outage: the next restorecon -R /, fixfiles, or /.autorelabel reverts it and the service breaks weeks later with no obvious cause. The equivalence between mv/cp and label behaviour is worth committing to muscle memory:

Cause 2 — Unregistered port

Network types are guarded too. Policy knows which port types a domain may bind or connect to; if you run a service on a non-standard port, the policy must be told that port belongs to the right type. Run nginx on 8443 and you get { name_bind } denied on tcp_socket because 8443 is not (by default) an http_port_t.

Confirm and fix:

semanage port -l | grep -w http_port_t          # what ports http_port_t already covers
# http_port_t   tcp   80, 81, 443, 488, 8008, 8009, 8443, 9000

semanage port -a -t http_port_t -p tcp 8443     # ADD a port to a type
semanage port -m -t http_port_t -p tcp 8443     # MODIFY if the port already maps elsewhere
semanage port -d -t http_port_t -p tcp 8443     # DELETE the mapping

If -a errors with “port already defined,” the port belongs to a different type — one protocol/port pair maps to exactly one type — and you must move it with -m. Common services and their port types (so you register the right one, not a generic one):

Cause 3 — Boolean off

Booleans are switches the policy author exposes for common variations that would otherwise require different policies: “may httpd make outbound network connections,” “may it read user home directories,” “may Samba share home directories.” When audit2why names a boolean, flipping it is the fix — and the -P flag makes it persist across reboots. Omit -P and the change evaporates on the next restart, producing the classic “it worked until we rebooted” bug.

getsebool -a | grep httpd                       # every httpd boolean and its current state
semanage boolean -l | grep httpd_can_network    # includes the human-readable description
setsebool -P httpd_can_network_connect on        # PERSISTENT (writes to policy store)
setsebool httpd_can_network_connect on           # runtime-only — reverts on reboot (avoid)
getsebool httpd_can_network_connect              # confirm: ... --> on

High-value booleans you will actually reach for, and exactly what each unlocks:

The triage order that resolves most tickets: context, then port, then boolean. Run restorecon first, check semanage port -l, then getsebool -a. Only when all three are correct do you have a real policy gap.

Confined vs. unconfined — and why your daemon won’t start (or worse, “just works”)

Whether SELinux confines a service at all depends on labelling and a transition rule, and the failure modes here are the ones that trip up experienced admins.

• Confined services have an *_exec_t label on their binary and a type_transition into a dedicated domain (httpd_t, postgresql_t). Tightly boxed — this is the goal.
• Unconfined processes run in unconfined_t (interactive user sessions) or init_t (things systemd launched with no transition) and are barely restricted. A binary labelled only bin_t that systemd starts typically stays in init_t — effectively unconfined.

So when you drop in a third-party daemon, one of two things happens, and the worse outcome is the one that looks like success:

The “just works because it’s unconfined” case is the trap. You gain a false sense of security and, in an MCS/MLS environment, the daemon can both bypass confinement and still trip category denials on labelled files — worst of both worlds. Diagnose with the process domain, then read both the OS-level failure and the SELinux reason:

ps -eZ | grep my-daemon                          # init_t/unconfined_service_t = your red flag
journalctl -u my-daemon -b | tail -n 50          # the OS-level failure (exit code, stderr)
ausearch -m AVC -c my-daemon -ts recent          # the SELinux reason, if any

For a real daemon you want a dedicated confined domain — which means writing policy. That is the rest of this article.

Generate a starter with audit2allow — then stop and read it

audit2allow reads denials and emits the allow rules that would have permitted them. It is the fastest way to understand what a service needs and to scaffold a module. It is also the fastest way to punch a hole clean through your security posture if you ship its output unreviewed. Treat it as a checklist of needs, never as the artifact you load.

Generate a candidate module straight from the audit log. -M builds a named module — a human-readable mydaemon.te and a compiled mydaemon.pp in one step:

ausearch -m AVC -c my-daemon --raw | audit2allow -M mydaemon
# produces: mydaemon.te (source you MUST read) and mydaemon.pp (compiled package)

# or pipe from a saved log:
audit2allow -a -M mydaemon                        # -a reads all of audit.log

Now read mydaemon.te before doing anything else. audit2allow is mechanical; it will happily generate rules that defeat confinement entirely. Treat these as red flags and, wherever you see one, ask “what is the right fix?” — which is almost always a private type or a proper interface, not the raw rule:

The mental model: audit2allow answers “what would unblock this?” — it never answers “what should this service be allowed to do?” You answer the second question. Use the generated .te as a list of the operations the daemon attempted, then express each with the right construct (a private type, a named interface, a narrow allow) in a module you actually maintain.

Write a clean .te module with proper interfaces

A maintainable module uses the reference policy interfaces and macros instead of raw allow rules wherever possible. Interfaces — defined in .if files under /usr/share/selinux/devel/include — encapsulate the correct, complete set of rules for an operation, so you do not hand-roll fragile permission lists that break on the next policy update. Discover them with sepolicy:

dnf install -y selinux-policy-devel policycoreutils-devel   # provides the interfaces + Makefile

sepolicy interface -l | grep -i 'read.*log'         # discover interfaces by keyword
sepolicy interface -v logging_read_generic_logs     # show exactly what one expands to
sepolicy generate --init /usr/sbin/mydaemon         # scaffold a full .te/.if/.fc skeleton for a daemon

sepolicy generate --init is the right scaffolder (as opposed to audit2allow): it produces a .te, .if, and .fc skeleton with the domain declaration, the init_daemon_domain transition, and common interface calls already wired — a far better starting point than a pile of raw allows. The three source-file types you will write:

Here is a minimal but correct module for a hypothetical daemon mydaemon that listens on a TCP port, reads its config under /etc/mydaemon, and writes logs and a pidfile. Note the structure: a private domain, a transition from init, private data types, and named interfaces instead of bare rules.

policy_module(mydaemon, 1.0.0)

########################################
# Declarations
require {
    type init_t;
}

# The daemon's own domain, its executable label, and the init transition
type mydaemon_t;
type mydaemon_exec_t;
init_daemon_domain(mydaemon_t, mydaemon_exec_t)   # binary -> domain transition + entrypoint

# A PRIVATE port type this daemon (and nothing else) may bind
type mydaemon_port_t;
corenet_port(mydaemon_port_t)

# PRIVATE data types — the whole point of confinement
type mydaemon_conf_t;
files_config_file(mydaemon_conf_t)                 # marks it a config file type

type mydaemon_log_t;
logging_log_file(mydaemon_log_t)                   # marks it a log file type

type mydaemon_var_run_t;
files_pid_file(mydaemon_var_run_t)                 # marks it a runtime/pid file type

########################################
# Local policy

# Minimal capabilities — setgid/setuid to drop privileges after binding
allow mydaemon_t self:capability { setgid setuid };
allow mydaemon_t self:tcp_socket create_stream_socket_perms;

# Bind ONLY its own port type
allow mydaemon_t mydaemon_port_t:tcp_socket name_bind;

# Read its own configuration (pattern macros pull in dir search + file read)
read_files_pattern(mydaemon_t, mydaemon_conf_t, mydaemon_conf_t)
list_dirs_pattern(mydaemon_t, mydaemon_conf_t, mydaemon_conf_t)

# Manage its own logs, with a file transition so NEW logs get the right label
manage_files_pattern(mydaemon_t, mydaemon_log_t, mydaemon_log_t)
manage_dirs_pattern(mydaemon_t, mydaemon_log_t, mydaemon_log_t)
logging_log_filetrans(mydaemon_t, mydaemon_log_t, { file dir })

# Manage its own pidfile under /run, with a file transition
manage_files_pattern(mydaemon_t, mydaemon_var_run_t, mydaemon_var_run_t)
files_pid_filetrans(mydaemon_t, mydaemon_var_run_t, file)

# Standard plumbing almost every daemon needs
sysnet_dns_name_resolve(mydaemon_t)                # resolve hostnames
logging_send_syslog_msg(mydaemon_t)                # write to the syslog socket

Pair it with a file context (.fc) file so the labels are applied by path — this is what makes restorecon (and the module install) do the right thing forever:

/usr/sbin/mydaemon          --      gen_context(system_u:object_r:mydaemon_exec_t,s0)
/etc/mydaemon(/.*)?                 gen_context(system_u:object_r:mydaemon_conf_t,s0)
/var/log/mydaemon(/.*)?            gen_context(system_u:object_r:mydaemon_log_t,s0)
/run/mydaemon(/.*)?                gen_context(system_u:object_r:mydaemon_var_run_t,s0)

Why this beats the raw audit2allow dump: the daemon writes to its own private types, not to shared system types like var_log_t or etc_t. A compromise of mydaemon cannot touch other services’ logs or config, cannot bind other services’ ports, cannot read arbitrary /etc. That isolation is the entire value proposition, and you only get it by declaring private types and using file transitions. The macros doing the heavy lifting, decoded:

Build, load, and test safely

You have two compilation paths. The devel Makefile is the clean one for a real .te/.fc/.if set — it knows where the interfaces live and links them:

# requires selinux-policy-devel; run from the directory holding mydaemon.{te,fc,if}
make -f /usr/share/selinux/devel/Makefile mydaemon.pp

The manual path is useful when you have only a .te with no interface dependencies and want to see each step:

checkmodule -M -m -o mydaemon.mod mydaemon.te     # compile the module (-M enables MLS/MCS)
semodule_package -o mydaemon.pp -m mydaemon.mod \
    -f mydaemon.fc                                 # package .mod + .fc into a loadable .pp

Now the safe rollout. Never load a fresh module straight into enforcing on a production node. Install it, make only its domain permissive, relabel its files, and start it:

semodule -i mydaemon.pp                            # install (upgrade in place if re-run)
semanage permissive -a mydaemon_t                  # make ONLY this domain permissive
restorecon -Rv /usr/sbin/mydaemon /etc/mydaemon /var/log/mydaemon /run/mydaemon
systemctl restart mydaemon

Exercise every code path — start, reload, rotate logs, hit every endpoint, trigger error paths — then harvest any residual denials the domain logged while permissive. audit2allow -R suggests interfaces (the -R = reference policy) rather than raw allows, which is exactly what you want to fold back in:

ausearch -m AVC -c mydaemon -ts recent | audit2allow -R
# review the suggested interfaces, add the legitimate ones to mydaemon.te, rebuild

Fold the legitimate gaps into the .te (using the suggested interfaces, after review), rebuild, reinstall, then flip the domain to enforcing and confirm the log is clean:

make -f /usr/share/selinux/devel/Makefile mydaemon.pp
semodule -i mydaemon.pp
semanage permissive -d mydaemon_t                  # remove the exception → enforcing for it
systemctl restart mydaemon
ausearch -m AVC -c mydaemon -ts recent             # should now be EMPTY

The full lifecycle of module commands, so you never guess the flag:

To audit the loaded policy — verifying containment, diffing before/after a change, answering “can this domain really do X?” — sesearch and seinfo (from setools-console) are the query tools. Keep this reference for policy review and CI diffs:

MCS, MLS, and multi-level: the fourth field earns its keep

The level field — s0, s0:c1,c2, s0-s3:c0.c1023 — is the sensitivity-and-categories part of the context, and two schemes use it:

• MCS (Multi-Category Security) — the one you meet daily, because it is how containers are isolated. Each object gets categories (c0, c1, …). A process may access an object only if the process’s category set dominates the object’s. Podman/CRI-O assign each container a unique random pair like s0:c123,c456; a process in c123,c456 cannot read a file labelled c789,c012, so two containers on the same host, even running as the same UID with the same type (container_t), cannot read each other’s files. This is category isolation, and it is transparent until a volume mount trips it.
• MLS (Multi-Level Security) — the full Bell-LaPadula lattice (Unclassified < Secret < Top Secret), used in government/defence deployments running the mls policy rather than targeted. “No read up, no write down.” Rarely seen outside those contexts, but the mechanism is the same field.

The scheme comparison:

For containers, the practical knowledge is volume relabelling. When you bind-mount a host directory into a container, the host path has a normal type (say default_t or user_home_t) that container_t cannot read. Podman/Docker relabel on request:

# :z  -> relabel the volume as SHARED among containers (type svirt_sandbox_file_t / container_file_t)
# :Z  -> relabel as PRIVATE to THIS container (adds its unique MCS categories)
podman run -v /srv/appdata:/data:Z  myimage      # private, per-container categories
podman run -v /srv/shared:/data:z   myimage      # shared across containers

ls -Z /srv/appdata          # after :Z -> ...:container_file_t:s0:c123,c456

The :z/:Z distinction and its gotcha:

The classic container SELinux denial is a bind mount with no :z/:Z — the container gets Permission denied on /data even though the host mode bits are 0777, because the type is wrong. ls -Z on the host path plus ausearch -m AVC -ts recent (look for scontext=...container_t... and tcontext=...default_t...) confirms it, and adding :Z fixes it. There is also a boolean, container_use_cephfs and friends, and for the rare case where you must let containers touch host files broadly, setsebool -P container_manage_cgroup on and related switches — but reach for :Z first.

Architecture at a glance

There is no diagram for this topic — the model is a decision flow you run in your head, so picture it as a pipeline from symptom to fix. A request arrives at a confined daemon; the kernel’s LSM hook checks the DAC bits first, and only if those pass does it consult the SELinux policy. If the policy has an allow rule for scontext → operation → tcontext, the access proceeds silently. If not, the kernel writes an AVC record to audit.log and — in enforcing mode — returns EACCES to the process, which surfaces as a failed daemon, a 503, a “permission denied,” or a container that cannot read its volume.

Now trace the diagnostic path the way you would walk a flowchart. Every incident starts at one question: did SELinux actually block this? Run getenforce (are we even enforcing?) and ausearch -m AVC -ts recent (is there a denial, and is permissive=0?). A real denial routes down one of four branches by reading three fields. If the tcontext is a file type that looks wrong (default_t, user_home_t), you are on the labelling branch — restorecon, and register with semanage fcontext if the path is non-standard. If the permission is { name_bind }/{ name_connect } on a *_socket with a dest= port, you are on the port branch — semanage port -a. If audit2why names a boolean, you are on the boolean branch — setsebool -P. Only if all three are ruled out — labels correct, port registered, booleans on — do you reach the fourth branch: a genuine policy gap, where you scaffold with sepolicy generate/audit2allow -M, rewrite it cleanly with private types and interfaces, and roll it out under semanage permissive before flipping to enforcing.

The convergence point of every branch is the same instrument set: ps -eZ (is the actor in the domain you think?), ls -Z (is the target labelled the way you think?), ausearch/audit2why (what exactly was refused and why?), and sesearch/seinfo (what does the loaded policy actually say?). That is the whole method — localise the symptom to a branch by reading scontext, tcontext, and the permission; apply the branch’s fix; confirm with a clean ausearch. The mental picture is not a network diagram; it is this four-way fork, and the fastest engineers are the ones who read the three fields and pick the branch in seconds.

Real-world scenario

Meridian Pay, a fictional but representative payments processor, ran a fleet of about 40 RHEL 8 hosts under a hard PCI-DSS requirement: SELinux stays enforcing, no exceptions, audited quarterly by an external QSA. The platform team was six engineers; the constraint on the wall read “setenforce 0 is a reportable incident.”

The trouble started when a vendor shipped a new log-shipping agent — a closed-source Go binary dropped at /opt/vendor/bin/shipper, started by a systemd unit — that refused to work correctly after install. systemctl status shipper showed the process running, so the on-call engineer nearly closed the ticket, but downstream the central log platform showed no data arriving. journalctl -u shipper was unhelpful (a generic “failed to open source” line). The vendor’s documentation, predictably, said: “If logs are not shipping, run setenforce 0.” On this fleet that instruction was a non-starter.

The breakthrough came from asking the right first question. ps -eZ | grep shipper revealed the real problem: the agent was running in init_t — completely unconfined — because its binary was labelled bin_t and there was no policy module to transition it. So SELinux was not confining it at all, yet it was still failing, which seemed contradictory. ausearch -m AVC -c shipper -ts recent explained it: the agent needed to read every other service’s logs under /var/log to ship them, and even an unconfined process in init_t trips category and type denials when it reaches into files labelled for other confined domains (httpd_log_t, postgresql_log_t, and MCS-categorised files). The agent was getting { read } denied on those precise files — the worst-of-both-worlds case: unconfined enough to be a security hole, still confined enough to fail.

The team refused both the vendor’s setenforce 0 and the lazy audit2allow -a -M shipper dump (which would have granted dac_read_search and broad var_log_t writes — a QSA red flag). Instead they gave the agent a real domain and exactly one tightly scoped read interface:

policy_module(shipper, 1.0.0)

require { type init_t; }
type shipper_t;
type shipper_exec_t;
init_daemon_domain(shipper_t, shipper_exec_t)

# read existing logs only — no write, no create, no delete
logging_read_all_logs(shipper_t)
allow shipper_t self:capability { dac_read_search };   # to traverse other services' log dirs
sysnet_dns_name_resolve(shipper_t)                     # resolve the log platform's hostname
allow shipper_t self:tcp_socket create_stream_socket_perms;

They labelled the binary and rolled out safely rather than straight to enforcing:

semanage fcontext -a -t shipper_exec_t '/opt/vendor/bin/shipper'
restorecon -v /opt/vendor/bin/shipper
make -f /usr/share/selinux/devel/Makefile shipper.pp
semodule -i shipper.pp
semanage permissive -a shipper_t          # observe first, block nothing
systemctl restart shipper                 # now runs in shipper_t, confined
# ... exercise a full shipping cycle across all log sources, harvest residual denials ...
ausearch -m AVC -c shipper -ts recent | audit2allow -R
# ... one extra interface for the syslog socket added and reviewed ...
semanage permissive -d shipper_t          # flip shipper_t to enforcing

The outcome, as numbers: the agent moved from init_t (unconfined) to shipper_t (confined to read-only log access plus DNS and one outbound socket), logs flowed to the platform, and the residual ausearch -m AVC -c shipper was clean. The quarterly QSA review passed with no finding — and, tellingly, the security team could now point at sesearch -A -s shipper_t and prove the agent could read logs but not write anywhere, connect only outbound, and touch nothing else. The lesson written on the runbook: “A denial on an unconfined daemon means it needs a domain, not setenforce 0. Give it the smallest domain that works.”

The incident as a timeline, because the order of moves is the lesson:

Advantages and disadvantages

Type enforcement is powerful precisely because it is mandatory and default-deny, and those same properties are what make it feel obstructive until you learn to read it. Weigh it honestly:

The model is right for any internet-facing or multi-tenant host, any regulated workload, and anywhere a single daemon compromise must not become a full host compromise. It bites hardest on teams that treat every denial as an obstacle rather than data, on shops shipping in-house daemons with no policy, and on anyone who has normalised chcon-in-automation or setenforce 0-in-incidents. Every one of the disadvantages is manageable — but only if you know it exists, which is the entire point of this article.

Hands-on lab

Reproduce three classic denials (a mislabelled file, an unregistered port, an off boolean), then build and confine a tiny custom daemon end to end. Run on a RHEL 9 / Rocky 9 / AlmaLinux 9 VM you can throw away. Everything is reversible; teardown is at the end.

Step 0 — Confirm enforcing and install the tooling.

getenforce                                   # must print: Enforcing
sudo dnf install -y policycoreutils policycoreutils-devel \
    setroubleshoot-server selinux-policy-devel httpd

Expected: Enforcing, and the packages install (they provide semanage, sepolicy, audit2allow, sealert, and the devel Makefile).

Step 1 — Reproduce a wrong-file-context denial with httpd. Serve content from a non-standard directory and watch it fail:

sudo mkdir -p /srv/webdemo
echo '<h1>hello</h1>' | sudo tee /srv/webdemo/index.html
sudo sed -i 's#^DocumentRoot .*#DocumentRoot "/srv/webdemo"#' /etc/httpd/conf/httpd.conf
sudo systemctl restart httpd
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/index.html   # expect 403

Confirm it is SELinux, not Apache config:

sudo ausearch -m AVC -c httpd -ts recent | sudo audit2why | tail -n 8
# ... "you may need to relabel ..." OR a name_bind/read denial on default_t
ls -Z /srv/webdemo/index.html               # ...default_t... (wrong for httpd)

Step 2 — Fix it the right way: register the path, then restore.

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/webdemo(/.*)?'
sudo restorecon -Rv /srv/webdemo
ls -Z /srv/webdemo/index.html               # now ...httpd_sys_content_t...
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/index.html   # now 200

Validation: the curl returns 200, ls -Z shows httpd_sys_content_t, and a fresh ausearch -m AVC -c httpd -ts recent is empty.

Step 3 — Reproduce and fix an unregistered-port denial. Make httpd listen on 8443 (not in http_port_t by default? it is — so use 8888 which is not):

sudo sed -i 's/^Listen 80$/Listen 8888/' /etc/httpd/conf/httpd.conf
sudo systemctl restart httpd                # FAILS to bind
sudo ausearch -m AVC -c httpd -ts recent | tail -n 6
# ... avc: denied { name_bind } ... tclass=tcp_socket ... dest=8888 ...

sudo semanage port -a -t http_port_t -p tcp 8888   # register the port
sudo systemctl restart httpd                       # now starts
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8888/index.html   # 200

Validation: the service starts after semanage port -a, and semanage port -l | grep 8888 shows http_port_t tcp ... 8888.

Step 4 — Reproduce and fix a boolean denial. Have httpd make an outbound connection (simulate with a reverse-proxy or a script); the boolean httpd_can_network_connect gates it. Demonstrate the boolean directly:

getsebool httpd_can_network_connect          # httpd_can_network_connect --> off
sudo setsebool -P httpd_can_network_connect on
getsebool httpd_can_network_connect          # --> on   (and PERSISTENT thanks to -P)

Validation: the boolean reads on, and because you used -P it survives sudo reboot (the -P-less form would revert).

Step 5 — Build and confine a tiny custom daemon. Create a trivial daemon, give it a domain, and confine it. First the daemon and its unit:

sudo tee /usr/local/sbin/mydaemon >/dev/null <<'EOF'
#!/usr/bin/env bash
# a trivial "daemon": listen on a TCP port, log to its own log dir
mkdir -p /var/log/mydaemon
exec 2>>/var/log/mydaemon/mydaemon.log
echo "$(date) starting on 9099" >>/var/log/mydaemon/mydaemon.log
exec /usr/bin/ncat -lk -p 9099 -c 'echo ok'
EOF
sudo chmod 0755 /usr/local/sbin/mydaemon
sudo dnf install -y nmap-ncat

sudo tee /etc/systemd/system/mydaemon.service >/dev/null <<'EOF'
[Unit]
Description=mydaemon lab
[Service]
ExecStart=/usr/local/sbin/mydaemon
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start mydaemon
ps -eZ | grep mydaemon        # note: runs in init_t (UNCONFINED) — the trap

Now author the policy. Create mydaemon.te and mydaemon.fc:

cat > /tmp/mydaemon.te <<'EOF'
policy_module(mydaemon, 1.0.0)

require { type init_t; }

type mydaemon_t;
type mydaemon_exec_t;
init_daemon_domain(mydaemon_t, mydaemon_exec_t)

type mydaemon_port_t;
corenet_port(mydaemon_port_t)

type mydaemon_log_t;
logging_log_file(mydaemon_log_t)

allow mydaemon_t self:capability { setgid setuid };
allow mydaemon_t self:tcp_socket create_stream_socket_perms;
allow mydaemon_t mydaemon_port_t:tcp_socket name_bind;

manage_files_pattern(mydaemon_t, mydaemon_log_t, mydaemon_log_t)
manage_dirs_pattern(mydaemon_t, mydaemon_log_t, mydaemon_log_t)
logging_log_filetrans(mydaemon_t, mydaemon_log_t, { file dir })
EOF

cat > /tmp/mydaemon.fc <<'EOF'
/usr/local/sbin/mydaemon    --      gen_context(system_u:object_r:mydaemon_exec_t,s0)
/var/log/mydaemon(/.*)?             gen_context(system_u:object_r:mydaemon_log_t,s0)
EOF

Build, register the port and labels, install, and roll out permissive-first:

cd /tmp && make -f /usr/share/selinux/devel/Makefile mydaemon.pp
sudo semodule -i mydaemon.pp
sudo semanage port -a -t mydaemon_port_t -p tcp 9099
sudo restorecon -Rv /usr/local/sbin/mydaemon /var/log/mydaemon
sudo semanage permissive -a mydaemon_t        # bring up permissive, block nothing
sudo systemctl restart mydaemon
ps -eZ | grep mydaemon                        # now in mydaemon_t (confined)

Exercise it, harvest residual denials, then go enforcing:

printf '' | ncat localhost 9099               # hit the port a few times
sudo ausearch -m AVC -c mydaemon -ts recent | audit2allow -R   # review any gaps
sudo semanage permissive -d mydaemon_t        # flip mydaemon_t to enforcing
sudo systemctl restart mydaemon
sudo ausearch -m AVC -c mydaemon -ts recent   # should be empty

Step 6 — Validate the end state.

getenforce                                    # Enforcing
ps -eZ | grep mydaemon                        # mydaemon_t (NOT init_t)
sudo semodule -l | grep mydaemon              # module loaded
sudo semanage permissive -l | grep mydaemon   # NO output = enforcing for this domain
sudo sesearch -A -s mydaemon_t | head         # inspect the live allow rules
sudo seinfo -t | grep mydaemon                # your private types exist

Validation checklist: the process is in mydaemon_t, the module is listed, the permissive list does not mention mydaemon_t, and ausearch is clean.

Step 7 — Teardown. Reverse everything so the box is pristine:

sudo systemctl disable --now mydaemon
sudo rm -f /etc/systemd/system/mydaemon.service /usr/local/sbin/mydaemon
sudo systemctl daemon-reload
sudo semodule -r mydaemon                      # remove by NAME, not .pp
sudo semanage port -d -t mydaemon_port_t -p tcp 9099 2>/dev/null || true
sudo semanage port -d -t http_port_t -p tcp 8888 2>/dev/null || true
sudo semanage fcontext -d '/srv/webdemo(/.*)?' 2>/dev/null || true
sudo rm -rf /srv/webdemo /var/log/mydaemon
sudo setsebool -P httpd_can_network_connect off
sudo dnf remove -y httpd nmap-ncat 2>/dev/null || true
rm -f /tmp/mydaemon.*

Common mistakes & troubleshooting — the AVC-denial playbook

This is the reference you keep open at 02:00. Each row is a symptom you actually see, the root cause, the exact command to confirm it, and the fix. Read the prose once; keep the table open during the incident. The columns are deliberately in confirm-then-fix order — never fix before you have confirmed with ausearch/ls -Z/ps -eZ.

A few deserve a sentence beyond the table. Row 12 (invisible denials) is the one that makes people think SELinux breaks things “randomly”: the denial is real but dontaudit-silenced, and until you semodule -DB you debug blind — always try this when a service is clearly SELinux-affected yet ausearch is empty. Row 13 (permissive=1) is its inverse: chasing a “denial” that never blocked anything because that domain is permissive. Row 18 (relabel after Disabled) is why the standing advice is “permissive if worried, never disabled” — permissive keeps labels current, disabled lets them rot. And row 7 (unconfined init_t) is the quiet one: nothing fails, so no ticket is filed, yet the daemon has no protection at all — sweep for it proactively with ps -eZ.

Best practices

• Never setenforce 0 to fix a problem. Use it for at most a few seconds to prove SELinux is the cause, then flip it back and diagnose with ausearch. Keep SELINUX=enforcing in /etc/selinux/config permanently.
• Triage in order: context → port → boolean. Run restorecon -nv (dry run) and ls -Z first, then semanage port -l, then getsebool -a | audit2why. Reach for a custom module only after all three are correct.
• Always use the persistent form. setsebool -P, semanage fcontext -a (not chcon), semanage port -a. Anything runtime-only (setsebool without -P, chcon) is a reboot-or-relabel timebomb.
• restorecon, not chcon, in automation. Register the path with semanage fcontext -a and apply with restorecon. chcon belongs only in a throwaway experiment.
• Read every audit2allow .te before loading it. Treat execmem, dac_override, dac_read_search, sys_admin, and writes to shared system types (etc_t, var_log_t) as red flags demanding a private-type or interface fix instead.
• Give real daemons a real domain. A binary that lands in init_t is unconfined; write a module with init_daemon_domain() and a *_exec_t label so it transitions into a dedicated, minimal domain.
• Use private types, not shared ones. Your daemon writes to mydaemon_log_t, not var_log_t, and binds mydaemon_port_t, not a shared port type. Isolation is the whole point.
• Prefer reference-policy interfaces over raw allow. Discover them with sepolicy interface -l/-v and audit2allow -R. Interfaces stay correct across policy updates; hand-rolled permission lists rot.
• Roll out permissive-first, per domain. semanage permissive -a <domain>, exercise every code path, harvest residual denials, fold them in, then semanage permissive -d. Never load a fresh module straight into enforcing on production.
• Keep policy in version control and build it in CI. Treat .te/.fc/.if like code: make -f /usr/share/selinux/devel/Makefile, diff the loaded rules with sesearch, and review changes like any other patch.
• Re-enable dontaudit rules. If you ever semodule -DB to see silenced denials, always semodule -B afterwards, or you flood the log and can mask real signal.
• Prefer permissive over disabled, always. If you must relax SELinux temporarily, use permissive (labels stay current) — never disabled (labels rot and force a full relabel to recover).

Security notes

The security value of SELinux is containment, and every practice above either preserves or squanders it. Least privilege is the governing principle: a custom domain should be able to do exactly what the daemon needs and nothing more, which is why private types and narrow interfaces beat broad allows — a compromise of the daemon then reaches only its own config, its own logs, and its own port. Auditability is the second pillar: because every denial is logged with the exact actor and target, a confined, enforcing host produces a forensic trail that an unconfined one cannot; this is why the audit log this article reads pairs directly with Building a Linux Audit Trail with auditd and eBPF Runtime Visibility.

Specific hardening points that matter for this topic:

Two anti-patterns are security-relevant enough to restate: shipping raw audit2allow output trains your team to grant exactly the permissions a real exploit wants — execmem, dac_override, writes to system types — so read the .te every time; and running a daemon unconfined in init_t gives a false sense of protection worse than knowing you have none, because you will not compensate elsewhere. When in doubt, prove containment with sesearch -A -s <domain> — if you cannot point at the rules and say “it can do only this,” the module is not done.

Cost & sizing

SELinux has no licence cost — it ships in the kernel and the base OS on every RHEL-family and Fedora distribution — so the “cost” is entirely operational: engineering time to read denials, author and maintain policy, and a small, usually negligible, runtime overhead. Budget in INR/USD terms is about people, not infrastructure.

The sizing guidance is really a staffing observation: the marginal cost of keeping SELinux enforcing, once your team is fluent, is small — a few minutes per denial and a few hours per genuinely new daemon. The cost of not being fluent is where the money hides: a single setenforce 0 that turns a containable RCE into a full host compromise, or a failed audit, dwarfs any policy-authoring time. On the relabel front, size maintenance windows for a full fixfiles on your largest hosts and parallelise with restorecon -Rp where you can — but the best cost control is never going to Disabled, so a relabel is never forced on you.

Interview & exam questions

Q1. What is the difference between DAC and MAC, and which is checked first? DAC (discretionary access control) is the traditional Unix owner/group/mode model, where the resource owner decides access. MAC (mandatory access control) is SELinux’s system-wide policy that the owner cannot override. DAC is checked first; a SELinux denial in audit.log means DAC already passed and SELinux is the one refusing. Maps to RHCE/RHCSA and CIS hardening objectives.

Q2. In the context system_u:system_r:httpd_t:s0, which field does enforcement work, and what is it called for a process versus a file? The third field, the type. For a process it is called the domain (httpd_t); for a file it is the type or label (httpd_sys_content_t). In default targeted policy the user and role fields are largely inert; the type is what you troubleshoot.

Q3. Read this denial: avc: denied { name_bind } ... tclass=tcp_socket ... dest=8888. What’s wrong and how do you fix it? A domain tried to bind TCP port 8888, which is not registered to that domain’s port type. Confirm with semanage port -l | grep 8888 (absent), fix with semanage port -a -t <type>_port_t -p tcp 8888. This is the “port” branch of triage.

Q4. A file has -rw-r--r-- root root but a root process can’t read it. Why, and what do you run? The Unix mode bits allow it, so the block is SELinux: the file’s type is wrong for the reading domain (commonly after a mv preserved a foreign label). Confirm with ls -Z and ausearch -m AVC, fix with restorecon -Rv <path> (register with semanage fcontext first if the path is non-standard).

Q5. Why is chcon dangerous in a configuration-management role? chcon sets a label imperatively and does not register it in the fcontext database, so any subsequent restorecon -R, fixfiles, or /.autorelabel reverts it and the service breaks with no obvious cause. Use semanage fcontext -a + restorecon, which survives relabels.

Q6. What does setsebool -P do that setsebool alone does not? -P writes the boolean change to the policy store so it persists across reboots. Without -P the change is runtime-only and reverts on the next boot — the classic “it worked until we rebooted” bug.

Q7. A third-party daemon “works fine” but ps -eZ shows it in init_t. Is that good? No — init_t means it is effectively unconfined: its binary is only bin_t, so no transition fired and SELinux protects nothing. The fix is to write a module with an *_exec_t label and init_daemon_domain() so it transitions into a dedicated, minimal domain.

Q8. Why should you never blindly load audit2allow output? audit2allow answers “what would unblock this?”, not “what should this be allowed to do?” It will happily generate execmem, dac_override, and writes to shared system types — exactly the permissions an exploit wants. Read the .te, then express each need with private types and reference-policy interfaces.

Q9. How do you bring up a new confined daemon in production without risking an outage? Install the module, semanage permissive -a <domain> so only that domain logs-but-doesn’t-block, exercise every code path, harvest residual denials with ausearch ... | audit2allow -R, fold the legitimate ones in, rebuild, then semanage permissive -d <domain> to flip it to enforcing. The rest of the system stays enforcing throughout.

Q10. A container gets “permission denied” on a bind-mounted host directory that is chmod 0777. Why, and what’s the fix? The host path’s type is wrong for container_t (SELinux, not DAC, is refusing). Confirm with ls -Z on the host path (it shows a non-container type) and ausearch. Fix by mounting with :Z (relabel private to this container) or :z (relabel shared). This is MCS/container-selinux in action.

Q11. What does dontaudit do, and how can it mislead you during troubleshooting? dontaudit rules silence specific denials so they never reach the audit log. If a service is clearly broken by SELinux but ausearch shows nothing, a dontaudit rule may be hiding the denial. Disable them with semodule -DB, reproduce, then re-enable with semodule -B.

Q12. Why is going to Disabled worse than Permissive, even temporarily? In Disabled mode the kernel maintains no labels, so new and modified files never get a correct security.selinux xattr and the on-disk labels drift. Re-enabling then requires a full filesystem relabel (fixfiles onboot / /.autorelabel), which can be a long maintenance window. Permissive keeps labels current and is instantly reversible.

Quick check

1. In user:role:type:level, which field does the enforcement, and what is it called for a process?
2. You moved a web file with mv and now get a 403. What’s the one command that fixes the label, and why did mv cause it?
3. A denial reads { name_connect } ... tclass=tcp_socket. Which of the three triage branches (context/port/boolean) is this, and what’s a likely boolean too?
4. What flag makes a setsebool change survive a reboot, and what’s the failure mode without it?
5. Your custom daemon shows init_t in ps -eZ. What does that mean for its security, and what must a policy module provide to fix it?

Answers

1. The third field, the type; for a process it is called the domain (e.g. httpd_t). The user and role fields are largely inert in default targeted policy.
2. restorecon -Rv <path>. mv preserves the file’s existing security.selinux xattr (its old label, e.g. user_home_t), whereas cp lets the destination policy assign a fresh one (httpd_sys_content_t); restorecon resets it to what policy says the path should have.
3. It is the port branch — a service connecting/binding to an unregistered port; fix with semanage port -a -t <type> -p tcp <port>. For an outbound httpd connection the boolean httpd_can_network_connect (or the narrower httpd_can_network_connect_db) is frequently also required.
4. -P (persistent). Without it the change is runtime-only and reverts on the next reboot — the “works until reboot” bug.
5. init_t means the daemon is effectively unconfined — its binary is bin_t, no transition fired, and SELinux is protecting nothing. A module must provide an *_exec_t label on the binary and an entrypoint + type_transition (both from init_daemon_domain()) so it transitions into a dedicated confined domain.

Glossary

• AVC (Access Vector Cache) denial — the kernel’s log record of a refused access, written to /var/log/audit/audit.log; your primary diagnostic, read via ausearch.
• Boolean — a policy-author-provided on/off switch (e.g. httpd_can_network_connect) that toggles a common variation without writing policy; make persistent with setsebool -P.
• Context (security context) — the four-field user:role:type:level label carried by every process and object.
• DAC / MAC — discretionary access control (Unix owner/mode, checked first) versus mandatory access control (SELinux policy, checked after DAC passes).
• Domain — a process type (e.g. httpd_t); the actor (scontext) in every denial.
• dontaudit — a policy rule that silences a specific harmless denial so it never reaches the log; disable temporarily with semodule -DB.
• Enforcing / Permissive / Disabled — the three global SELinux modes: block+log, log-only, and off (no labels maintained).
• File context (.fc) — a policy source file mapping path regexes to types via gen_context(); what makes restorecon authoritative.
• init_daemon_domain(t, exec_t) — the reference-policy macro that declares a daemon domain, its entrypoint, and the init_t→domain transition in one call.
• Interface (.if) — a reusable, correct bundle of rules for an operation, defined under /usr/share/selinux/devel/include; call these instead of raw allow.
• Label — informally, a file’s type; stored in the security.selinux extended attribute on the inode.
• MCS (Multi-Category Security) — the categories part of the level field (s0:c1,c2) used to isolate containers and tenants on a shared host.
• MLS (Multi-Level Security) — the Bell-LaPadula sensitivity lattice (no read-up, no write-down) used by the mls policy in defence/government contexts.
• Per-domain permissive — making a single domain permissive with semanage permissive -a <domain> while the rest of the system stays enforcing; the safe way to bring up a new daemon.
• Policy module — a loadable .pp package built from .te/.fc/.if sources and installed with semodule -i.
• Port type — a type (e.g. http_port_t) that maps ports to the domains allowed to bind/connect them; managed with semanage port.
• restorecon — resets a file’s label to what the fcontext database says it should be; the default fix for a mislabelled file.
• scontext / tcontext / tclass — the source domain, target context, and object class fields of a denial; the three you read first.
• semanage — the tool that edits the persistent policy store: fcontext, port, boolean, permissive, and more.
• sepolicy — the tool to discover interfaces (interface -l/-v) and scaffold policy (generate --init).
• Type enforcement (TE) — the core model: an allowlist of “domain X may do Y to type Z” rules; default-deny.
• type_transition — the rule that moves a newly executed process into a new domain; why confined daemons auto-confine.
• Unconfined domain — a barely-restricted type (unconfined_t, init_t); a daemon that lands here has no real SELinux protection.

Next steps

• Authoring AppArmor Profiles: Confining Services on Ubuntu and Debian — the path-based MAC alternative you meet on Ubuntu/Debian; reading both makes the type-enforcement-versus-path trade-off concrete.
• Building a Linux Audit Trail with auditd and eBPF Runtime Visibility — go deeper on the same audit.log these denials land in, and correlate SELinux events with broader runtime visibility.
• Mastering systemd: Units, Timers, Resource Control, and Service Hardening — the layer that transitions daemons into their domains, plus complementary sandboxing (ProtectSystem, PrivateTmp, capability bounding).
• Running Rootless Containers in Production with Podman and Quadlet — where MCS categories keep containers isolated; apply the :z/:Z volume-labelling knowledge from this article.
• Designing Stateful Linux Firewalls with native nftables Rulesets and NAT — pair network-layer controls with SELinux’s port-type enforcement for defence in depth.