On a RHEL host with SELinux enforcing, a daemon that starts fine on its default port fails to bind after you reconfigure it to listen on port 8081. Why would SELinux be involved in a port bind at all, and what is the correct fix?

## Labels are not only for files The usual introduction to SELinux is about files, so the first time a policy blocks something that has no path at all it looks like a different system entirely. It is not. SELinux assigns a security context to many *object classes*, and TCP and UDP port numbers are one of them. The policy maintains a mapping from port numbers and protocols to types, and its allow rules are written over those types just as they are for files. So when a confined daemon calls `bind()`, the kernel asks whether that domain is allowed the `name_bind` permission on a socket whose port carries type X. Its default port is already mapped to the type its domain is permitted to bind. An arbitrary alternative port is not — it will fall under some other type, or under a generic one — and the bind is refused. ## The symptom and the record The application reports something like "permission denied" or "could not bind to address", and the mode bits offer no explanation because there are no mode bits involved. The audit record is the giveaway: `tclass=tcp_socket` and a permission of `name_bind` (or `name_connect`, when the problem is a confined process reaching *out* to an unusual port), with `tcontext` naming the port's type rather than a file type. This is also the reason to read `tclass` on every denial rather than skipping to the fix. `tclass=file` sends you to labelling and `restorecon`; `tclass=tcp_socket` sends you here; `tclass=capability` says the application is asking for a privilege and no relabelling will help. ## The correct fix Inspect and change the mapping with `semanage port`: ```bash # what is 8081 currently, and what does this domain's type cover? semanage port -l | grep -E '8081|http_port_t' # add a port to an existing type semanage port -a -t http_port_t -p tcp 8081 # modify a port that is already mapped elsewhere semanage port -m -t http_port_t -p tcp 8081 # and remove a local addition when it is no longer needed semanage port -d -t http_port_t -p tcp 8081 ``` The change is a local policy modification: it persists across reboots, survives policy package updates, and is exactly as narrow as the problem — one port, one protocol, one type. Note that `-a` fails if the port is already mapped, which is what `-m` is for, and that some ports are already covered by broad type definitions, in which case nothing needs doing at all. ## What not to do The two shortcuts both cost more than they save. Switching the machine to permissive removes containment from every confined service on the host because one port number is not in a list. Writing a policy module from the denial grants the domain `name_bind` on that port *type*, which is usually broader than adding your one port to the right type and is certainly harder for the next person to understand. There is also a distinct failure that looks similar and is not SELinux at all: binding a port below 1024 requires privilege, historically root and now more precisely a capability the process must hold. If the port in question is low, rule that out first — the denial record will name a capability rather than a socket class, and no amount of `semanage port` will help. ## Why this question is worth knowing It is the cheapest possible demonstration that a candidate understands SELinux as a labelling system rather than as "the thing that breaks file permissions". Anyone who has moved a service off its default port on a RHEL-family host has met it; anyone who has only read about SELinux usually has not. It also sets up the more general habit that matters in production: read the object class in the denial, and let it choose which of the several possible fixes is the right one.