SELinux in practice: labels, ports and booleans

Steps 1 to 7 run on rocky01 and build a small nginx site in /srv/web on port 8090, with a pretend API behind it on port 3000. Everything is tested from rocky01 itself with curl, so firewalld stays as it is. Step 8 runs on ubu01.

The Break-It section reuses this site and ends with a clean-up that removes it all.

1Check the SELinux mode

Run this on rocky01:

getenforce
sestatus
grep -E '^SELINUX(TYPE)?=' /etc/selinux/config

You should see something like this:

Enforcing
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33
SELINUX=enforcing
SELINUXTYPE=targeted

Current mode is what the kernel does now; mode from config file is what it will do after the next boot. They should both say enforcing. The policy is targeted, and policy version 33 is the newest policy format this kernel can load.

If yours says permissive, fix it now with sudo setenforce 1 and set SELINUX=enforcing in the file.

✅ Checkpoint: getenforce prints Enforcing and the config file says SELINUX=enforcing.

2Read the labels on you, a few services and a few files

Run this:

id -Z
ps -eZ | grep -E 'chronyd$|sshd$'
ls -Z /etc/shadow
ls -Zd ~
ls -Zd /srv

You should see something like this:

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
system_u:system_r:chronyd_t:s0       798 ?        00:00:00 chronyd
system_u:system_r:sshd_t:s0-s0:c0.c1023 1012 ? 00:00:00 sshd
system_u:object_r:shadow_t:s0 /etc/shadow
unconfined_u:object_r:user_home_dir_t:s0 /home/student
system_u:object_r:var_t:s0 /srv

Your shell is unconfined_t, which is why commands you type are rarely stopped. chronyd and sshd each run in their own domain, chronyd_t and sshd_t. /etc/shadow is shadow_t, which only a few domains (login, passwd, sshd through PAM) may read. Your home folder is user_home_dir_t and the files inside it are user_home_t. /srv is var_t, a type web servers aren’t allowed to read.

✅ Checkpoint: You can name the type (the third part) of each label in the output.

3Install nginx and the SELinux tools, then look at nginx’s domain

Run this:

sudo dnf install -y nginx policycoreutils-python-utils setroubleshoot-server
sudo systemctl enable --now nginx
ps -eZ | grep nginx
ls -Zd /usr/share/nginx/html
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/

You should see something like this (after the dnf output):

system_u:system_r:httpd_t:s0       3101 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       3102 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       3103 ?        00:00:00 nginx
system_u:object_r:httpd_sys_content_t:s0 /usr/share/nginx/html
200

policycoreutils-python-utils gives you semanage and audit2why, and setroubleshoot-server gives you sealert. The nginx master and its two workers (one per vCPU) all run as httpd_t. Its default web root is httpd_sys_content_t, so the welcome page loads with 200.

✅ Checkpoint: All nginx processes show httpd_t and curl prints 200.

4Serve a new folder: add the path rule, then relabel

Create the folder and a page, then check its label:

sudo mkdir -p /srv/web
echo '<h1>rocky01 web lab</h1>' | sudo tee /srv/web/index.html
ls -Zd /srv/web

You should see this:

<h1>rocky01 web lab</h1>
unconfined_u:object_r:var_t:s0 /srv/web

The new folder took var_t from /srv. nginx would get “Permission denied” on it. Tell the policy what this path is, then apply the rule to what’s already there:

Run this:

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?'
sudo restorecon -Rv /srv/web
sudo semanage fcontext -l -C

You should see something like this:

Relabeled /srv/web from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
Relabeled /srv/web/index.html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
SELinux fcontext                                   type               Context

/srv/web(/.*)?                                     all files          system_u:object_r:httpd_sys_content_t:s0

The pattern /srv/web(/.*)? means the folder itself plus everything under it, and it must be in single quotes. restorecon changed only the type and printed each file it fixed (-v). semanage fcontext -l -C lists only your local rules, which is the first thing to check on a server someone else built.

✅ Checkpoint: /srv/web and index.html both show httpd_sys_content_t, and your rule appears in semanage fcontext -l -C.

5Label a new port for nginx

See which ports nginx may use, add 8090, and check again:

sudo semanage port -l | grep -w http_port_t
sudo semanage port -a -t http_port_t -p tcp 8090
sudo semanage port -l | grep -w http_port_t

You should see something like this:

http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
http_port_t                    udp      80, 443
http_port_t                    tcp      8090, 80, 81, 443, 488, 8008, 8009, 8443, 9000
http_port_t                    udp      80, 443

8090 now sits at the front of the list, where semanage puts local additions. Now give nginx a server block for the site and for the API you’ll add next:

Paste this whole block:

sudo tee /etc/nginx/conf.d/lab41.conf > /dev/null <<'EOF'
server {
    listen 8090;
    root /srv/web;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
    }
}
EOF
sudo nginx -t && sudo systemctl restart nginx
curl -s http://127.0.0.1:8090/

You should see this:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
<h1>rocky01 web lab</h1>

nginx -t checks the syntax first, and the && only restarts if the check passed. Because the port was labelled before the restart, nginx could bind 8090 straight away. From another machine you’d also need the port open in firewalld (Lesson 34).

✅ Checkpoint: curl on port 8090 returns the rocky01 web lab page.

6Find a denial with ausearch and audit2why

Start a small backend on port 3000 as student, then call it directly and through nginx:

mkdir -p ~/lab41/api && echo 'api ok' > ~/lab41/api/index.html
python3 -m http.server 3000 --bind 127.0.0.1 --directory ~/lab41/api > /dev/null 2>&1 &
sleep 1
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8090/api/
getsebool httpd_can_network_connect

You should see something like this:

[1] 3188
200
502
httpd_can_network_connect --> off

The backend answers directly with 200, but through nginx you get 502 Bad Gateway, which is nginx saying “I couldn’t reach the upstream”. Look for the denial:

Run this:

sudo ausearch -m AVC -ts recent
sudo ausearch -m AVC -ts recent | audit2why

You should see something like this (ausearch also prints PROCTITLE and SYSCALL lines, cut here):

----
time->Tue Oct 27 11:52:20 2026
type=AVC msg=audit(1793082140.417:512): avc:  denied  { name_connect } for  pid=3102 comm="nginx" dest=3000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket permissive=0

type=AVC msg=audit(1793082140.417:512): avc:  denied  { name_connect } for  pid=3102 comm="nginx" dest=3000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket permissive=0

	Was caused by:
	The boolean httpd_can_network_connect was set incorrectly.
	Description:
	Allow httpd to can network connect

	Allow access by executing:
	# setsebool -P httpd_can_network_connect 1

Read the AVC from left to right: denied, the action name_connect, process nginx, destination port 3000, source httpd_t, target ntop_port_t (3000 is labelled for an old monitoring tool called ntop). -ts recent means the last 10 minutes. audit2why points at a boolean, and here it’s right: a reverse proxy needs to connect out.

✅ Checkpoint: You found an AVC with comm=”nginx”, dest=3000 and tcontext ntop_port_t, and audit2why names httpd_can_network_connect.

7Read it in plain English with sealert, then fix it

Run this:

sudo sealert -a /var/log/audit/audit.log

You should see something like this (shortened):

100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/nginx from name_connect access on the tcp_socket port 3000.

*****  Plugin connect_ports (85.9 confidence) suggests   *********************

If you want to allow /usr/sbin/nginx to connect to network port 3000
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 3000
    where PORT_TYPE is one of the following: dns_port_t, http_port_t, ...

*****  Plugin catchall_boolean (7.33 confidence) suggests   ******************

If you want to allow httpd to can network connect
Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.

Do
setsebool -P httpd_can_network_connect 1

sealert gives two suggestions with a confidence score. The first, changing the type of port 3000, would fail anyway because 3000 already has a type (you’d need -m instead of -a), and it would affect everything that uses ntop_port_t. For a reverse proxy, the boolean is the standard answer:

Run this:

sudo setsebool -P httpd_can_network_connect on
getsebool httpd_can_network_connect
curl -s http://127.0.0.1:8090/api/

You should see this:

httpd_can_network_connect --> on
api ok

-P writes the value into the policy on disk, which takes a few seconds, so it survives reboots. semanage boolean -l | grep httpd_ shows every web server boolean with its current and default value and a one-line description.

✅ Checkpoint: getsebool shows on and curl through port 8090 prints api ok.

8See AppArmor on ubu01

Run this on ubu01:

sudo aa-status | head -n 9
sudo aa-status | grep -A1 'processes are in enforce'
ps -eZ | grep rsyslogd

You should see something like this (counts differ between installs):

apparmor module is loaded.
112 profiles are loaded.
26 profiles are in enforce mode.
   /usr/bin/man
   lsb_release
   man_filter
   man_groff
   rsyslogd
   ...
1 processes are in enforce mode.
   /usr/sbin/rsyslogd (812) rsyslogd
rsyslogd (enforce)                  812 ?        00:00:00 rsyslogd

AppArmor ties a profile to a program path, so rsyslogd is confined by the profile in /etc/apparmor.d/usr.sbin.rsyslogd. Most of the other loaded profiles are for desktop apps and sit in unconfined mode, which Ubuntu uses to control user namespaces. To see the two main modes, install the tools and flip rsyslogd to complain mode and back:

sudo apt install -y apparmor-utils
sudo aa-complain /usr/sbin/rsyslogd
sudo aa-status | grep -A1 'profiles are in complain'
sudo aa-enforce /usr/sbin/rsyslogd

You should see something like this:

Setting /usr/sbin/rsyslogd to complain mode.
1 profiles are in complain mode.
   rsyslogd
Setting /usr/sbin/rsyslogd to enforce mode.

Complain mode is AppArmor’s permissive: it logs what the profile would block (apparmor=”ALLOWED” in journalctl -k) but blocks nothing. Enforce mode blocks and logs apparmor=”DENIED”. As with SELinux, complain is for finding out, not for leaving on.

✅ Checkpoint: rsyslogd is back in enforce mode, and aa-status lists it under processes in enforce mode.