{"id":167939,"date":"2026-05-23T18:19:25","date_gmt":"2026-05-23T15:19:25","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=167939"},"modified":"2026-05-23T20:29:11","modified_gmt":"2026-05-23T17:29:11","slug":"selinux-survival-fedora","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/selinux-survival-fedora\/","title":{"rendered":"SELinux Survival Guide for Fedora 44 \/ 43 \/ 42"},"content":{"rendered":"

The first time SELinux blocks something on a fresh Fedora install, the temptation is to run setenforce 0<\/code> and move on. Don’t. That trades a five-minute policy fix for an unconfined system, and walks away from the most effective Linux exploit-mitigation layer the kernel ships with. The real skill is learning to read the audit log, identify what was actually denied, and apply the narrowest possible policy adjustment to allow it. Four tools do almost all of the work: ausearch<\/code> and sealert<\/code> to read denials, semanage port<\/code> for non-standard ports, setsebool<\/code> for behaviour toggles, and semanage fcontext<\/code> plus restorecon<\/code> for custom paths.<\/p>\n\n

This guide is the survival manual we wish was bundled into every Fedora install. It walks the mental model first (contexts, type enforcement, domain transitions), then the four fix paths with real audit.log<\/code> output from a hands-on test box, then ten server and desktop scenarios that cover almost every denial you will hit in practice: Nginx on a non-standard port and custom webroot, PostgreSQL with an alternate data directory, Podman bind-mounts, SSH on a different port, Samba on a user home, custom systemd services, Flatpak sandbox blocks, browsers reading external drives. Every command was executed on a real Fedora install and the outputs are captured, not invented.<\/p>\n\n

Tested May 2026<\/strong> on Fedora 44 (kernel 7.0.8-200.fc44) with selinux-policy-targeted 44.1, policycoreutils 3.10, audit 4.1.4, setroubleshoot-server 3.3.36, libselinux 3.10. Verified on Fedora 43 and Fedora 42 clones; every command in this guide works unchanged across the three releases. The mental model and toolset apply identically to RHEL 10, Rocky Linux 10, and AlmaLinux 10.<\/em><\/p>\n\n

How SELinux actually works (in five minutes)<\/h2>\n\n

SELinux is a kernel module that enforces a Mandatory Access Control (MAC) layer on top of normal Unix permissions. Where Unix asks “is this UID allowed to read this file?”, SELinux asks a second question: “is the domain this process is running in<\/em> allowed to read a file with this type label<\/em>, in this MCS category<\/em>?”. The DAC check is the lock on your front door. The MAC check is the alarm system that fires even when the front door is open, because someone stole the key.<\/p>\n\n

The default Fedora policy is targeted<\/code>. It confines the system services that talk to the network or run as root (httpd, sshd, NetworkManager, postgresql, dovecot, podman, systemd-resolved) and leaves interactive user sessions running in unconfined_t<\/code>. That choice is deliberate: it gives you most of the security benefit without making the desktop unusable. If you want every login session confined, the Fedora hardening guide<\/a> covers the staff_u<\/code> and user_u<\/code> roles, the harder configuration that RHEL ships for regulated environments.<\/p>\n\n

Anatomy of an SELinux context<\/h3>\n\n

Every process, every file, every port carries a label that looks like this:<\/p>\n\n\n

system_u:system_r:httpd_t:s0\n   |        |        |     |\n   |        |        |     +-- MCS \/ MLS sensitivity (s0 = no constraint)\n   |        |        +-------- type (the most important field)\n   |        +----------------- role\n   +-------------------------- SELinux user (NOT the Unix user)<\/code><\/pre>\n\n\n
For targeted policy, only the type<\/strong> field is enforced. Read a context as “everything before :s0<\/code> describes what kind of thing this is”. A process labelled httpd_t<\/code> is the Nginx or Apache daemon. A file labelled httpd_sys_content_t<\/code> is content that the webserver is allowed to read. A port labelled http_port_t<\/code> is a TCP port that webservers are allowed to bind to. The policy is a giant table of allow rules between these types, and the kernel checks every syscall against it.<\/p>\n\n
Look at the labels on a few real objects to make this concrete:<\/p>\n\n\n
ls -Z \/usr\/sbin\/sshd \/etc\/shadow \/var\/log\/audit\nid -Z<\/code><\/pre>\n\n\n
The output makes the policy intent obvious. The sshd binary is sshd_exec_t<\/code> so systemd transitions to sshd_t<\/code> when it runs. The shadow file is shadow_t<\/code> so only a handful of utilities can touch it. The audit log directory is auditd_log_t<\/code> so only auditd writes there:<\/p>\n\n\n
system_u:object_r:sshd_exec_t:s0 \/usr\/sbin\/sshd\nsystem_u:object_r:shadow_t:s0 \/etc\/shadow\nsystem_u:object_r:auditd_log_t:s0 \/var\/log\/audit\nunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023<\/code><\/pre>\n\n\n
Your interactive shell is unconfined_t<\/code> with the full MCS range c0.c1023<\/code>, which is why you can read almost anything without policy fighting you. The constraint kicks in for the daemons.<\/p>\n\n
Domain transitions: how a binary becomes a daemon<\/h3>\n\n
When systemd runs \/usr\/sbin\/sshd<\/code>, the policy ships a type_transition<\/code> rule that says “an init_t process executing an sshd_exec_t file transitions to sshd_t”. The new sshd process starts life in the locked-down sshd_t<\/code> domain even though systemd ran it. The same mechanism turns nginx into httpd_t<\/code>, postgresql into postgresql_t<\/code>, podman into container_runtime_t<\/code>, and so on. When you write a custom systemd service, your binary inherits init_t<\/code> unless you label the executable with a known service type, which is one of the gotchas covered in the server scenarios below.<\/p>\n\n
Confirm SELinux is enforcing<\/h2>\n\n
Every Fedora install ships with SELinux enforcing the targeted policy. Confirm with the two status commands; they should agree:<\/p>\n\n\n
getenforce\nsestatus\nid -Z<\/code><\/pre>\n\n\n
On a default Fedora box you see Enforcing<\/code>, the longer sestatus<\/code> dump that reports the policy name and version, and the context for your shell:<\/p>\n\n\n
\"getenforce,<\/figure>\n\n\n
The Max kernel policy version: 35<\/code> line indicates Fedora is running the modern policy format. Older Fedora releases on the same series of policy versions show identical enforcing posture; the syntax of every command below is identical. If getenforce<\/code> returns Disabled<\/code>, someone has flipped the kernel boot to bypass SELinux entirely (selinux=0<\/code> on the kernel command line or an entry in \/etc\/selinux\/config<\/code>). That state requires a full filesystem relabel to recover from, which is why the post-install setup guide<\/a> covers the boot-state checks worth running on every fresh Fedora install.<\/p>\n\n
Install the troubleshooting toolset<\/h2>\n\n
The default install ships policycoreutils<\/code> (the setenforce<\/code>, restorecon<\/code>, semodule<\/code> binaries) but not the higher-level diagnostic tools you actually need. Pull them in one transaction:<\/p>\n\n\n
sudo dnf5 install -y policycoreutils-python-utils setools-console setroubleshoot-server<\/code><\/pre>\n\n\n
That gives you three categories of tools. semanage<\/code> and semodule<\/code> are the policy-management CLIs. sesearch<\/code>, seinfo<\/code>, matchpathcon<\/code> are the query tools for inspecting the loaded policy. sealert<\/code> plus the setroubleshoot-server<\/code> daemon are the plain-English denial explainers that watch the audit log and write human-readable summaries to the journal as denials happen. The DNF5 cheatsheet<\/a> covers the broader package-manager flags worth knowing for any troubleshooting session.<\/p>\n\n
Audit log fundamentals<\/h2>\n\n
SELinux denials end up in three places, and knowing which to read in which situation saves a lot of time. The kernel writes Access Vector Cache (AVC) entries to \/var\/log\/audit\/audit.log<\/code>. The setroubleshootd<\/code> daemon watches that file and writes plain-English summaries to the journal via journalctl<\/code>. sealert<\/code> reads the raw log on demand and prints structured suggestions. journalctl -u nginx<\/code> shows the service-level error but rarely the denial itself, which is the single most common reason an SELinux problem looks like a generic Permission denied<\/code> at first.<\/p>\n\n
Reading denials with ausearch<\/h3>\n\n
One real gotcha worth memorising before you spend an hour debugging: ausearch -m AVC --start recent<\/code> often returns <no matches><\/code> on a fresh denial because the search relies on auditd’s internal cursor, which can lag the on-disk file. Read the file directly with -if<\/code> and the matches appear immediately:<\/p>\n\n\n
sudo ausearch -i -if \/var\/log\/audit\/audit.log -m AVC --start recent<\/code><\/pre>\n\n\n
The -i<\/code> flag interprets numeric IDs (UIDs, syscall numbers, timestamps) into human-readable text. -if<\/code> tells ausearch<\/code> to read the file rather than the daemon’s cursor. Use this form whenever ausearch -m AVC<\/code> seems to silently miss denials you know happened.<\/p>\n\n
Anatomy of an AVC entry<\/h3>\n\n
A single AVC denial captured during the nginx test in the next section looks like this:<\/p>\n\n\n
type=AVC msg=audit(05\/23\/2026 17:06:14.179:446) : avc:  denied  { name_bind }\n  for  pid=8458 comm=nginx src=8888\n  scontext=system_u:system_r:httpd_t:s0\n  tcontext=system_u:object_r:unreserved_port_t:s0\n  tclass=tcp_socket permissive=0<\/code><\/pre>\n\n\n
Read it field by field. The denied<\/code> keyword says the kernel blocked the operation. The braced operation { name_bind }<\/code> is the access vector that was checked. scontext<\/code> is the source domain (the process trying to do the thing): nginx running in httpd_t<\/code>. tcontext<\/code> is the target context (the thing being accessed): a TCP port labelled unreserved_port_t<\/code>. tclass<\/code> is the object class (port, file, dir, socket). permissive=0<\/code> confirms the system was enforcing when the block fired. Once you can read this without thinking, every fix path follows from the fields.<\/p>\n\n
sealert and setroubleshootd<\/h3>\n\n
For each AVC, setroubleshootd<\/code> runs a set of plugins that suggest specific fixes scored by confidence. The output is what most people actually use to debug because it tells you the exact command to run:<\/p>\n\n\n
sudo sealert -a \/var\/log\/audit\/audit.log | head -20<\/code><\/pre>\n\n\n
The bind_ports<\/code> plugin scores 92.2 confidence and tells you semanage port -a -t http_port_t -p tcp 8888<\/code> is the right move. The lower-confidence catchall<\/code> plugin suggests an audit2allow<\/code> module as a last resort:<\/p>\n\n\n
\"Raw<\/figure>\n\n\n
For interactive debugging the sealert<\/code> command is the right entry point; for automation, parsing audit.log<\/code> directly with ausearch -i -if<\/code> is faster and avoids the daemon-cursor lag covered above.<\/p>\n\n
The dontaudit cache<\/h3>\n\n
SELinux silently suppresses a long list of low-noise denials via “dontaudit” rules to keep the log readable. When you are chasing a chain of denials where the first denial triggers a downstream one that the policy normally hides, disable dontaudit temporarily, reproduce, then re-enable:<\/p>\n\n\n
sudo semodule -DB\n# reproduce the workflow that triggers the denial\nsudo ausearch -i -if \/var\/log\/audit\/audit.log -m AVC --start recent\nsudo semodule -B<\/code><\/pre>\n\n\n
Always re-enable when you are done. The dontaudit rules exist because keeping them logged would drown out the denials that actually matter.<\/p>\n\n
Trigger a real denial: nginx on a non-standard port and custom webroot<\/h2>\n\n
The fastest way to internalise SELinux troubleshooting is to break something on purpose, watch the denial land, then walk through the fix paths. Install nginx and switch it to a non-standard port plus a non-default webroot:<\/p>\n\n\n
sudo dnf5 install -y nginx\nsudo mkdir -p \/srv\/web\/myapp\necho \"<h1>Hello SELinux<\/h1>\" | sudo tee \/srv\/web\/myapp\/index.html<\/code><\/pre>\n\n\n
Edit the main config and set the listen port to 8888, the root to the new directory:<\/p>\n\n\n
sudo vi \/etc\/nginx\/nginx.conf<\/code><\/pre>\n\n\n
Inside the default server {}<\/code> block, set:<\/p>\n\n\n
listen       8888;\nlisten       [::]:8888;\nroot         \/srv\/web\/myapp;<\/code><\/pre>\n\n\n
Start the service. Both denials fire (the port bind first, then the file read after the port fix lands):<\/p>\n\n\n
sudo systemctl start nginx<\/code><\/pre>\n\n\n
The service exits with code 1, the journal shows bind() to 0.0.0.0:8888 failed (13: Permission denied)<\/code>, and the audit log holds the AVC. sealert -a \/var\/log\/audit\/audit.log<\/code> spells out exactly what to do. The next three sections cover the three production fix paths in order of how often you reach for them.<\/p>\n\n
Fix path 1: setsebool for behaviour toggles<\/h2>\n\n
Booleans are the first thing to try because they are pre-shipped, well-named, and reversible with a single command. The policy ships hundreds of toggles for behaviours the security team considered risky enough to default off but useful enough to expose: outbound network connects from web daemons, NFS-mounted home directories, mod_userdir, SFTP chroot writes, and so on. The Nginx-as-reverse-proxy case is the most common one in production. Enumerate the relevant booleans first:<\/p>\n\n\n
sudo getsebool -a | grep ^httpd_can<\/code><\/pre>\n\n\n
Output is the set of toggles that govern outbound httpd connections. Each is a one-line on\/off switch, persisted in policy:<\/p>\n\n\n
httpd_can_check_spam --> off\nhttpd_can_connect_ftp --> off\nhttpd_can_connect_ldap --> off\nhttpd_can_network_connect --> off\nhttpd_can_network_connect_cobbler --> off\nhttpd_can_network_connect_db --> off\nhttpd_can_network_memcache --> off\nhttpd_can_network_redis --> off\nhttpd_can_sendmail --> off<\/code><\/pre>\n\n\n
Flip the right one on. The -P<\/code> flag writes the change to disk so it survives reboot; without it the setting lasts only until the next boot:<\/p>\n\n\n
sudo setsebool -P httpd_can_network_connect on\nsudo getsebool httpd_can_network_connect<\/code><\/pre>\n\n\n
For the human-readable name of every boolean, list with semanage<\/code> instead of getsebool<\/code>; it pulls the description string from the policy:<\/p>\n\n\n
sudo semanage boolean -l | grep httpd_can_network<\/code><\/pre>\n\n\n
The 366 booleans on a stock Fedora cover most of the real-world denials you will hit. The categories worth knowing by name are httpd_*<\/code> for web servers, container_*<\/code> for podman and docker, samba_*<\/code> for file sharing, ftpd_*<\/code> for FTP, virt_*<\/code> for libvirt, git_*<\/code> for Gitolite and friends, and selinuxuser_*<\/code> for desktop sessions:<\/p>\n\n\n
\"getsebool<\/figure>\n\n\n
The general rule when reading a fresh denial: identify the source domain from the AVC (httpd_t<\/code>, ssh_t<\/code>, postgresql_t<\/code>) and grep for booleans whose name starts with that domain’s prefix. If a boolean fits the behaviour, flip it; you are done.<\/p>\n\n
Fix path 2: semanage port for non-standard ports<\/h2>\n\n
When the denial is name_bind<\/code> on a port the daemon’s domain is not allowed to bind, the fix is to teach the policy that the port belongs to the daemon’s port type. Before changing anything, see what ports the policy already allows for that type:<\/p>\n\n\n
sudo semanage port -l | grep ^http_port_t<\/code><\/pre>\n\n\n
Stock Fedora ships 80, 81, 443, 488, 8008, 8009, 8443, 9000 in http_port_t<\/code> for TCP. Add 8888:<\/p>\n\n\n
sudo semanage port -a -t http_port_t -p tcp 8888\nsudo semanage port -l | grep ^http_port_t<\/code><\/pre>\n\n\n
The list now includes 8888 at the front. Restart nginx; the bind succeeds and the service stays active. curl -sI http:\/\/localhost:8888\/<\/code> returns either 200 if the webroot is labelled correctly or 403 if the file context still needs the second fix:<\/p>\n\n\n
\"semanage<\/figure>\n\n\n
The change is written into the local policy module store, survives reboot, and survives package upgrades. To remove the rule later, swap -a<\/code> for -d<\/code>:<\/p>\n\n\n
sudo semanage port -d -t http_port_t -p tcp 8888<\/code><\/pre>\n\n\n
A common variation is moving an existing port type rather than adding to it. For SSH on a non-standard port, the ssh_port_t<\/code> set starts at 22 and you cannot -a<\/code> a port to a type that already declares it elsewhere; you have to -m<\/code> (modify) the set. The SSH non-standard-port scenario later in this guide walks the full sequence.<\/p>\n\n
Fix path 3: semanage fcontext and restorecon for custom paths<\/h2>\n\n
Files inherit the SELinux label of the directory you create them in. Put the webroot under \/srv\/web\/myapp<\/code> instead of the policy-default \/usr\/share\/nginx\/html<\/code>, and the files get labelled var_t<\/code>, which httpd_t is not allowed to read. The fix is two commands: tell the policy what the label should be for that path, then apply it.<\/p>\n\n
Confirm the wrong label first with ls -laZ<\/code>, then ask the policy what label the path should<\/em> have with matchpathcon<\/code>:<\/p>\n\n\n
ls -laZ \/srv\/web\/myapp\/\nsudo matchpathcon \/srv\/web\/myapp\/index.html \/usr\/share\/nginx\/html\/index.html<\/code><\/pre>\n\n\n
matchpathcon<\/code> compares against the loaded fcontext rules and tells you the difference. The policy-default webroot returns httpd_sys_content_t<\/code>; the custom path returns the generic var_t<\/code> because no rule covers it. Add the rule, then apply it to the existing files:<\/p>\n\n\n
sudo semanage fcontext -a -t httpd_sys_content_t \"\/srv\/web\/myapp(\/.*)?\"\nsudo restorecon -Rv \/srv\/web\/myapp<\/code><\/pre>\n\n\n
The regex (\/.*)?<\/code> on the fcontext rule means “this directory and everything under it, optionally”. The restorecon -Rv<\/code> walks the tree and applies the rule, printing each file it relabels:<\/p>\n\n\n
\"matchpathcon<\/figure>\n\n\n
Files you create later under \/srv\/web\/myapp<\/code> get the right label automatically because the rule sits in the policy database, not the filesystem metadata. To inspect existing local rules, use -C<\/code> for “custom” (rules added on top of the default policy):<\/p>\n\n\n
sudo semanage fcontext -l -C\nsudo semanage boolean -l -C\nsudo semanage port -l -C<\/code><\/pre>\n\n\n
The custom view is invaluable when you inherit a server with months of accumulated policy tweaks and you want to know what is different from a fresh install.<\/p>\n\n
chcon vs restorecon: pick the right one<\/h3>\n\n
Two commands change file labels and they have very different semantics. chcon<\/code> sets a label on a single file directly, ignoring the policy database. restorecon<\/code> reads the policy database and applies the rule that matches the path. A label set with chcon<\/code> survives until something runs restorecon<\/code> on the file, at which point it reverts to the database value. A label set via semanage fcontext<\/code> + restorecon<\/code> is permanent because it lives in the database.<\/p>\n\n\n
sudo touch \/tmp\/testfile\nls -Z \/tmp\/testfile\nsudo chcon -t etc_t \/tmp\/testfile\nls -Z \/tmp\/testfile\nsudo restorecon -v \/tmp\/testfile\nls -Z \/tmp\/testfile<\/code><\/pre>\n\n\n
The first ls -Z<\/code> shows user_tmp_t<\/code>, chcon<\/code> rewrites it to etc_t<\/code>, and restorecon<\/code> resets it to user_tmp_t<\/code> using the rule for \/tmp<\/code>. Always reach for semanage fcontext<\/code> + restorecon<\/code> for anything that should persist.<\/strong> The only legitimate use of chcon<\/code> is a one-off relabel during interactive debugging, never something you check into a config-management repo.<\/p>\n\n
Server scenarios you will actually hit<\/h2>\n\n
The nginx walk-through above is the canonical example but it is one of many. The scenarios below are the ones we have hit on real production builds, each with the AVC pattern and the fix in the same paragraph so you can map a real denial back to the right command.<\/p>\n\n
Nginx or Apache as reverse proxy to an upstream service<\/h3>\n\n
The denial pattern: httpd_t<\/code> tries to open a TCP socket to http_port_t<\/code> or postgresql_port_t<\/code> on a different host, blocked by name_connect<\/code>. The fix is a boolean, not a port or path change:<\/p>\n\n\n
sudo setsebool -P httpd_can_network_connect on\n# If the upstream is a database specifically:\nsudo setsebool -P httpd_can_network_connect_db on\n# For Memcached \/ Redis specifically:\nsudo setsebool -P httpd_can_network_memcache on\nsudo setsebool -P httpd_can_network_redis on<\/code><\/pre>\n\n\n
The narrow booleans are preferable to the broad httpd_can_network_connect<\/code> when you know exactly which upstream you talk to, because the rest of the egress stays blocked.<\/p>\n\n
PostgreSQL with a non-default data directory<\/h3>\n\n
The denial pattern: postgresql_t<\/code> tries to open or write files labelled default_t<\/code> or var_t<\/code> at the new data path. The fix is the same fcontext pattern as nginx but with the postgresql label type:<\/p>\n\n\n
export PG_DATA=\/srv\/pgdata\nsudo semanage fcontext -a -t postgresql_db_t \"${PG_DATA}(\/.*)?\"\nsudo restorecon -Rv \"${PG_DATA}\"\nsudo systemctl restart postgresql<\/code><\/pre>\n\n\n
The postgresql_db_t<\/code> type is the one the policy expects under \/var\/lib\/pgsql\/data<\/code>; mirroring it on the custom path is what lets the daemon read and write. If you also moved the unix socket to a non-default directory, you need postgresql_var_run_t<\/code> on the socket directory; if you put the WAL on a separate filesystem, postgresql_db_t<\/code> on that path too.<\/p>\n\n
MariaDB or MySQL on a non-default port<\/h3>\n\n
The denial pattern: mysqld_t<\/code> bind on unreserved_port_t<\/code> blocked. The fix is a port add into mysqld_port_t<\/code>:<\/p>\n\n\n
sudo semanage port -l | grep ^mysqld_port_t\nsudo semanage port -a -t mysqld_port_t -p tcp 3307<\/code><\/pre>\n\n\n
The same pattern applies for any daemon: read the AVC, look up the matching port type, add to it. The port-type names follow a convention (http_port_t<\/code>, ssh_port_t<\/code>, postgresql_port_t<\/code>, mysqld_port_t<\/code>, postfix_smtpd_port_t<\/code>), so if you can name the service you can usually guess the type.<\/p>\n\n
SSH on a non-standard port<\/h3>\n\n
The denial pattern: sshd_t<\/code> bind on a port outside ssh_port_t<\/code>. SSH is special because port 22 is already in the type by default and the policy refuses to add a second SSH port without confirming the move. The clean sequence:<\/p>\n\n\n
sudo semanage port -l | grep ^ssh_port_t\n# ssh_port_t  tcp  22\n\n# Add the new port. -a is the right verb here even though 22 is also in\n# the type; the modifier is on the set, not the type.\nsudo semanage port -a -t ssh_port_t -p tcp 2222\n\n# Confirm\nsudo semanage port -l | grep ^ssh_port_t\n# ssh_port_t  tcp  2222, 22<\/code><\/pre>\n\n\n
Pair the SELinux change with the firewalld update (firewall-cmd --add-port=2222\/tcp --permanent<\/code>) and the matching Port 2222<\/code> entry in \/etc\/ssh\/sshd_config<\/code>; sshd binds and survives a reboot. The firewalld walkthrough<\/a> covers the network policy layer that sits in front of the SELinux layer.<\/p>\n\n
Custom systemd service running an interpreted script<\/h3>\n\n
The denial pattern: a systemd unit launches \/opt\/myapp\/serve.py<\/code>, the process inherits init_t<\/code> (because \/opt\/myapp\/serve.py<\/code> is labelled usr_t<\/code> with no type-transition rule), and any later operation that init_t<\/code> is not allowed gets blocked. The first fix to try is moving the script under \/usr\/local\/bin<\/code> so it picks up bin_t<\/code> and behaves like a normal binary. If the script has to live elsewhere, declare the path as bin_t<\/code>:<\/p>\n\n\n
sudo semanage fcontext -a -t bin_t \"\/opt\/myapp\/serve\\.py\"\nsudo restorecon -v \/opt\/myapp\/serve.py\nsudo systemctl restart myapp<\/code><\/pre>\n\n\n
For services that need a custom domain (not running as init_t<\/code>), you write a policy module that declares the type and the transition; the audit2allow<\/code> path later in this guide covers the minimum boilerplate.<\/p>\n\n
Samba sharing user home directories<\/h3>\n\n
The denial pattern: smbd_t<\/code> tries to read user_home_t<\/code> files and is blocked because home directories are not normally Samba-exposed. The boolean covers it:<\/p>\n\n\n
sudo setsebool -P samba_enable_home_dirs on\n# If the share also writes (not just reads), also:\nsudo setsebool -P use_samba_home_dirs on<\/code><\/pre>\n\n\n
Same pattern for Apache mod_userdir: httpd_enable_homedirs<\/code> is the matching toggle.<\/p>\n\n
NFS-mounted home directories or web content<\/h3>\n\n
The denial pattern: any daemon trying to read or write on an NFS mount gets blocked because the policy treats NFS-mounted files as nfs_t<\/code> regardless of what the actual label “should” be (NFS does not transport labels by default). The fix is the boolean that authorises the daemon’s type for NFS:<\/p>\n\n\n
sudo setsebool -P httpd_use_nfs on\nsudo setsebool -P virt_use_nfs on\nsudo setsebool -P use_nfs_home_dirs on<\/code><\/pre>\n\n\n
For label-aware NFS (NFSv4.2 with seclabel<\/code> mount option), you can transport real labels across the wire; that is the configuration to reach for when you run a heterogeneous Fedora and RHEL fleet sharing home directories.<\/p>\n\n
Mail: Postfix submission, Dovecot deliver_t<\/h3>\n\n
The denial pattern usually comes from a non-default mail spool location. Postfix runs as postfix_master_t<\/code> with helper domains for each pipeline stage; Dovecot’s deliver agent is dovecot_deliver_t<\/code>. If the spool moves from \/var\/mail<\/code>, the matching fcontext add is:<\/p>\n\n\n
sudo semanage fcontext -a -t mail_spool_t \"\/srv\/mail(\/.*)?\"\nsudo restorecon -Rv \/srv\/mail<\/code><\/pre>\n\n\n
For Postfix listening on submission ports outside the default set, smtp_port_t<\/code> covers the standard SMTP, submission, and submissions ports; only non-standard ports need a port add.<\/p>\n\n
Cockpit on a custom port<\/h3>\n\n
The denial pattern: cockpit bind on a port outside websm_port_t<\/code>. Cockpit is the management dashboard Fedora ships on port 9090 by default. Move it and SELinux blocks the bind until the port is registered:<\/p>\n\n\n
sudo semanage port -a -t websm_port_t -p tcp 9091<\/code><\/pre>\n\n\n
Cockpit also runs spawn-on-demand for SSH terminals, so any non-default SSH port has to be in ssh_port_t<\/code> (covered above) for the in-browser terminal to work end-to-end.<\/p>\n\n
Container scenarios: SELinux + Podman<\/h2>\n\n
Containers add a second layer to the type model: the entire container runs in container_t<\/code> and the host filesystem objects it can touch are labelled container_file_t<\/code> with an MCS category pair unique to that container instance. The MCS categories are what isolate one container from another even when they run as the same Unix UID. If you have Podman with Quadlet running<\/a>, every container gets its own MCS pair automatically and the daemons never see each other’s filesystems.<\/p>\n\n
The :Z \/ :z bind-mount labels<\/h3>\n\n
The most common Podman SELinux problem is a bind-mount from the host that the container cannot read. The mount works fine at the Linux level (the kernel mounted the directory) but SELinux blocks the access because the source directory is labelled user_home_t<\/code> and container_t<\/code> is not allowed to read it. Podman has two suffix flags that fix this at mount time:<\/p>\n\n\n
# Lowercase :z = shared label (relabel as container_file_t with no MCS)\npodman run -d -p 9001:80 -v ~\/html:\/usr\/share\/nginx\/html:z nginx:alpine\n\n# Uppercase :Z = exclusive label (relabel with this container's MCS pair)\npodman run -d -p 9002:80 -v ~\/html:\/usr\/share\/nginx\/html:Z nginx:alpine<\/code><\/pre>\n\n\n
Use :Z<\/code> when only one container should access the directory (almost always the right choice). Use :z<\/code> when several containers share a directory. Both relabel the host directory permanently, so do not point them at \/etc<\/code> or anywhere else with system-owned labels:<\/p>\n\n\n
\"Podman<\/figure>\n\n\n
The label after :Z<\/code> includes the per-container MCS pair (c130,c527<\/code> in the example). Two different containers each get their own pair from a 524,288-entry namespace, so even if both bind-mount the same parent directory, one container’s :Z<\/code> mount cannot read the other’s data.<\/p>\n\n
Container booleans worth knowing<\/h3>\n\n
The container subsystem ships a dozen booleans, most of which you never touch. Enumerate them once so you know what is there, then keep the short list of the ones that actually matter in production:<\/p>\n\n\n
sudo getsebool -a | grep ^container_<\/code><\/pre>\n\n\n
The toggles most likely to matter in production:<\/p>\n\n\n\n
Boolean<\/th>When to flip on<\/th><\/tr><\/thead>\n
container_use_cgroup<\/code><\/td>Containers need cgroup access (resource limits, systemd-in-container)<\/td><\/tr>\n
container_manage_cgroup<\/code><\/td>Containers create cgroups (systemd as PID 1 inside)<\/td><\/tr>\n
container_connect_any<\/code><\/td>Container processes need to connect to any TCP port on host<\/td><\/tr>\n
virt_sandbox_use_all_caps<\/code><\/td>Sandboxed containers needing the full capability set<\/td><\/tr>\n<\/tbody>\n<\/table>\n\n
For a privileged container that genuinely needs to bypass the SELinux model (almost always wrong, but useful for kernel debugging containers), pass --security-opt label=disable<\/code> on the podman run<\/code> command line. The container then runs as spc_t<\/code> (Super Privileged Container) and the type-enforcement check is skipped for that one container only, the rest of the system stays enforcing.<\/p>\n\n
Rootless Podman and user namespaces<\/h3>\n\n
Rootless containers add a third layer: the user namespace maps the container’s root<\/code> UID to an unprivileged UID on the host. SELinux still applies at the kernel level. If a rootless container tries to write to ~\/data<\/code> with a :Z<\/code> mount, the relabel writes a system-level label on a file your user owns; if you later delete the container, the directory keeps the container_file_t label until restorecon<\/code> resets it. The cleanup command worth memorising:<\/p>\n\n\n
sudo restorecon -Rv ~\/data<\/code><\/pre>\n\n\n
The Distrobox and Toolbox setup<\/a> shows how SELinux contexts get re-mapped inside those container managers, which lean on the same bind-mount semantics shown here.<\/p>\n\n
Desktop scenarios<\/h2>\n\n
Workstation users hit SELinux less often than server admins because the targeted policy leaves interactive sessions unconfined. The denials you will see fall into three categories: confined services your desktop talks to (NetworkManager, polkit, GDM), Flatpak sandboxes, and applications that try to read non-default paths (USB drives, network mounts, mounted ISOs).<\/p>\n\n
Flatpak applications hitting the sandbox<\/h3>\n\n
Flatpak apps run under their own sandbox (Bubblewrap) on top of SELinux. When a Flatpak app needs to read a host file it does not have a portal for, the denial shows in the audit log as spc_t<\/code> reading the host path. The pattern: the file should be accessible via a portal (Documents, Camera, Network), and the right answer is granting the portal permission, not loosening SELinux:<\/p>\n\n\n
# Grant home directory read access to a Flatpak app\nflatpak override --user --filesystem=home com.example.App\n\n# Grant network access (already default for most apps)\nflatpak override --user --share=network com.example.App<\/code><\/pre>\n\n\n
For Flatpak apps that need to talk to a host daemon (Steam to talk to Joystick, a media player to talk to GPU), the right knob is on the Flatpak side, not the SELinux side. flatseal<\/code> on Flathub gives you a GUI for the same overrides.<\/p>\n\n
Firefox or Chrome reading from a USB drive<\/h3>\n\n
The denial pattern: the browser tries to read a file under \/run\/media\/${USER}<\/code> labelled removable_t<\/code>. The boolean exists:<\/p>\n\n\n
sudo setsebool -P mozilla_read_content on<\/code><\/pre>\n\n\n
The flag covers Mozilla-derived browsers (Firefox, Thunderbird) reading external mounts, which is more often a concern in kiosk or shared-workstation setups than on a personal laptop.<\/p>\n\n
VS Code or other editors writing under home<\/h3>\n\n
The desktop session is unconfined_t<\/code>, so VS Code under your Unix UID is unconstrained at the SELinux level. The only time you see a denial is when the editor’s language server spawns a child process that is<\/em> confined (for example, python_t<\/code> for a development server), and the child tries to read files outside user_home_t<\/code>. The fix is on the language server’s domain, not the editor.<\/p>\n\n
Steam, Lutris, and games installing to non-default paths<\/h3>\n\n
Putting the Steam library on a second drive with a custom mount point gets the directory labelled fs_t<\/code> or default_t<\/code>, and games crash when they try to write save files there. Declare the mount point as user_home_t<\/code> if it is genuinely user data:<\/p>\n\n\n
sudo semanage fcontext -a -t user_home_t \"\/mnt\/games(\/.*)?\"\nsudo restorecon -Rv \/mnt\/games<\/code><\/pre>\n\n\n
For Steam Proton, this also covers the per-game prefix data under \/mnt\/games\/steamapps\/compatdata<\/code>.<\/p>\n\n
GNOME extensions and custom application launchers<\/h3>\n\n
GNOME extensions installed via extensions.gnome.org<\/code> live under ~\/.local\/share\/gnome-shell\/extensions<\/code> and inherit gnome_home_t<\/code>. Extensions that spawn subprocesses (clipboard managers, network indicators) sometimes hit denials when the subprocess needs to read a system file the extension does not normally touch. The right fix here is almost always a bug report against the extension; a one-off chcon<\/code> is fine while you debug but should never become a permanent workaround.<\/p>\n\n
Last resort: audit2allow for custom policy modules<\/h2>\n\n
For the rare denial where no boolean exists, no port type fits, and no fcontext rule applies, generate a custom policy module from the audit log. This is the last resort because it writes a new rule rather than reusing an existing one, and a hand-written rule is the kind of thing that goes wrong silently when the policy updates and the rule no longer applies cleanly.<\/p>\n\n\n
cd \/tmp\nsudo ausearch -if \/var\/log\/audit\/audit.log -m AVC --start recent | \\\n  sudo audit2allow -M cfg-demo\n\nls -la cfg-demo*<\/code><\/pre>\n\n\n
audit2allow -M cfg-demo<\/code> emits both a human-readable source file (cfg-demo.te<\/code>) and a compiled policy module (cfg-demo.pp<\/code>). Always read the .te<\/code> file before installing the module so you know what you are granting:<\/p>\n\n\n
\"audit2allow<\/figure>\n\n\n
If the rules look too broad (“allow process X to do everything to type Y”), edit the .te<\/code> file to remove the over-broad permissions, then re-compile with checkmodule<\/code> and semodule_package<\/code>. When the rules look right, install:<\/p>\n\n\n
sudo semodule -i cfg-demo.pp\nsudo semodule -l | grep cfg-demo<\/code><\/pre>\n\n\n
The module is now loaded and persists across reboots. To remove it later:<\/p>\n\n\n
sudo semodule -r cfg-demo<\/code><\/pre>\n\n\n
Read the comment #!!!! This avc can be allowed using the boolean 'X'<\/code> in the generated .te<\/code> file before you install. audit2allow<\/code> includes those hints when it detects an existing boolean that would solve the same problem; that boolean is almost always the better fix.<\/p>\n\n
Permissive mode is for diagnostics, not for fixing<\/h2>\n\n
The wrong move when a complex application hits a chain of denials is setenforce 0<\/code>, which puts the entire system in permissive mode and removes confinement from every confined service at once. The right move is per-domain permissive, which logs denials without blocking them for one domain while every other service stays enforcing:<\/p>\n\n\n
sudo semanage permissive -a httpd_t\n# reproduce the workflow, collect every denial from the run:\nsudo ausearch -i -if \/var\/log\/audit\/audit.log -m AVC --start recent\n# fix each denial properly, then remove the per-domain permissive:\nsudo semanage permissive -d httpd_t<\/code><\/pre>\n\n\n
The semodule -l | grep permissive<\/code> command lists the per-domain permissive modules that are currently loaded; clean this list at the end of every debugging session so you do not leave services unconfined by accident.<\/p>\n\n
Policy queries with sesearch and seinfo<\/h2>\n\n
When the AVC names types you do not recognise, the setools-console<\/code> queries answer “what does this type let you do?” and “what types can do this?” The two commands worth knowing:<\/p>\n\n\n
# Who can write to \/etc\/shadow?\nsudo sesearch -A -t shadow_t -c file -p write\n\n# What can httpd_t do to httpd_sys_content_t?\nsudo sesearch -A -s httpd_t -t httpd_sys_content_t -c file\n\n# What domain transitions exist out of init_t?\nsudo sesearch -T -s init_t | head\n\n# Describe a single type\nsudo seinfo --type=sshd_t -x<\/code><\/pre>\n\n\n
The shadow query returns the short list of system utilities that legitimately rewrite passwords: passwd_t<\/code>, useradd_t<\/code>, groupadd_t<\/code>, updpwd_t<\/code>, sysadm_passwd_t<\/code>. The httpd query shows that httpd_t<\/code> can read httpd_sys_content_t<\/code> files by default, and can write them only when both httpd_unified<\/code> and httpd_enable_cgi<\/code> booleans are on. The init_t transitions list is several thousand entries long because almost every service comes through systemd; piping to head<\/code> or grepping for the service name you care about is the only way to read it.<\/p>\n\n
Confining users with semanage login<\/h2>\n\n
Targeted policy leaves interactive logins as unconfined_u<\/code> by default, but you can move a user into one of the confined SELinux user roles. The four built-in roles worth knowing:<\/p>\n\n\n\n
SELinux user<\/th>Confinement level<\/th><\/tr><\/thead>\n
unconfined_u<\/code><\/td>No confinement (default for all interactive logins)<\/td><\/tr>\n
staff_u<\/code><\/td>Can sudo<\/code> and su<\/code>, otherwise confined; the right choice for admins on a hardened box<\/td><\/tr>\n
user_u<\/code><\/td>No sudo<\/code>, no su<\/code>, no setuid binaries; the right choice for shared shell accounts<\/td><\/tr>\n
sysadm_u<\/code><\/td>Confined administrator; sudo<\/code> works but admin tools are constrained<\/td><\/tr>\n<\/tbody>\n<\/table>\n\n
Map a Unix user to one of those roles:<\/p>\n\n\n
sudo semanage login -a -s staff_u jmutai\nsudo semanage login -l<\/code><\/pre>\n\n\n
The new mapping kicks in on the next login because pam_selinux<\/code> assigns the SELinux context at session start. Verify with a fresh SSH session: id -Z<\/code> shows the new context, and attempting an operation outside the role (for example, switching to root<\/code> directly without going through sudo<\/code>) gets blocked by the policy regardless of the Unix permission check passing.<\/p>\n\n
MCS categories: per-process and per-container isolation<\/h2>\n\n
The trailing s0-s0:c0.c1023<\/code> on contexts is the MCS (Multi-Category Security) component. For targeted policy, it is what isolates instances of the same domain from each other. Two containers both running as container_t<\/code> on the same UID still cannot read each other’s filesystems because each got assigned a different MCS pair (c130,c527<\/code> vs c812,c901<\/code>) at startup, and the type-enforcement rules require category-set intersection for access.<\/p>\n\n
You will not write MCS rules by hand. The cases where MCS matters are:<\/p>\n\n