SELinux Policy Customization and Enforcement for Custom Linux Web Applications

When deploying bespoke web applications, microservices, or custom runtime environments on enterprise Linux distributions such as RHEL, Rocky Linux, or AlmaLinux, system administrators and DevOps engineers frequently encounter permission denied errors caused by Security-Enhanced Linux. Rather than systematically authoring domain policies, many teams succumb to the dangerous anti-pattern of running setenforce 0, effectively crippling the kernel’s Mandatory Access Control (MAC) subsystem and exposing the operating system to full compromise upon an application-layer vulnerability. Deploying resilient, high-density infrastructure on platforms like CpanelFree demands a zero-trust posture where custom daemons operate within rigorously scoped security domains tailored specifically to their runtime requirements.

Understanding Custom SELinux Policy Architecture for Linux Web Applications

At its core, SELinux shifts access evaluation from Discretionary Access Control (DAC)—which relies solely on standard Linux user/group permissions (rwxrwxrwx)—to a Mandatory Access Control (MAC) model governed by the security server within the Linux kernel. Under MAC, every process (subject) and every resource (object, such as files, directories, sockets, and ports) is bound to an immutable security context comprising four distinct attributes: user:role:type:level.

For custom web applications—whether built on Go, Node.js, Python ASGI/WSGI, Rust, or custom PHP-FPM pools—the third attribute, known as the Type (or domain when applied to a process), represents the fundamental boundary of isolation. When a custom web daemon is assigned a dedicated type (e.g., mywebapp_t), the kernel consults its active Access Vector Cache (AVC). Unless a rule explicitly permits mywebapp_t to interact with a target object type (such as reading mywebapp_content_t or binding to mywebapp_port_t), access is immediately denied and logged to /var/log/audit/audit.log.

Comparative Matrix: Application Isolation Strategies

Understanding the operational trade-offs between unconfined execution, generic web domains (httpd_t), and purpose-built custom SELinux policy modules is vital when hardening production environments.

Designing a Custom SELinux Policy Module

Creating an enterprise-grade SELinux policy involves defining three complementary configuration components: the Type Enforcement (.te) file, the File Contexts (.fc) file, and an optional Interface (.if) file. Rather than relying on lazy audit2allow capture after runtime failures—which frequently over-provisions permissions—architects must construct the domain using standard Reference Policy macros.

1. The Type Enforcement Definition (mywebapp.te)

The Type Enforcement file declares the process domain, associated file types, permissible capability sets, network bindings, and system transitions. Below is a production-hardened policy module designed for a custom Go/Node.js web application listening on TCP port 8080, writing logs to /var/log/mywebapp, and communicating with local Redis and PostgreSQL services.

policy_module(mywebapp, 1.0.0)

########################################
# Declarations
########################################

# Process domain for the daemon
type mywebapp_t;
type mywebapp_exec_t;
init_daemon_domain(mywebapp_t, mywebapp_exec_t)

# Filesystem types
type mywebapp_content_t;
files_type(mywebapp_content_t)

type mywebapp_rw_t;
files_type(mywebapp_rw_t)

type mywebapp_log_t;
logging_log_file(mywebapp_log_t)

# Network port declaration
type mywebapp_port_t;
corenet_port(mywebapp_port_t)

########################################
# Policy Rules for mywebapp_t
########################################

# Allow execution and process management
allow mywebapp_t self:process { fork signal sigkill sigchild };
allow mywebapp_t self:fifo_file rw_fifo_file_perms;
allow mywebapp_t self:unix_stream_socket create_stream_socket_perms;

# Allow reading application binaries and static content
read_files_pattern(mywebapp_t, mywebapp_content_t, mywebapp_content_t)
read_lnk_files_pattern(mywebapp_t, mywebapp_content_t, mywebapp_content_t)
list_dirs_pattern(mywebapp_t, mywebapp_content_t, mywebapp_content_t)

# Allow read/write/create on runtime mutable data (cache, uploads)
manage_dirs_pattern(mywebapp_t, mywebapp_rw_t, mywebapp_rw_t)
manage_files_pattern(mywebapp_t, mywebapp_rw_t, mywebapp_rw_t)

# Allow logging to /var/log/mywebapp
logging_search_logs(mywebapp_t)
manage_dirs_pattern(mywebapp_t, mywebapp_log_t, mywebapp_log_t)
manage_files_pattern(mywebapp_t, mywebapp_log_t, mywebapp_log_t)

# Network access: Bind to custom TCP port (8080)
allow mywebapp_t mywebapp_port_t:tcp_socket { name_bind listen accept };
allow mywebapp_t self:tcp_socket create_stream_socket_perms;

# Network access: Outbound connections to PostgreSQL and Redis
corenet_tcp_connect_postgresql_port(mywebapp_t)
corenet_tcp_connect_redis_port(mywebapp_t)

# DNS resolution and system time lookup
sysnet_dns_name_resolve(mywebapp_t)
miscfiles_read_localization(mywebapp_t)

2. The File Contexts Specification (mywebapp.fc)

The File Contexts file maps disk directory hierarchies and regex patterns to their definitive security contexts. This ensures that maintenance utilities like restorecon correctly reset filesystem labels to the desired baseline.

# Binary executable
/usr/local/bin/mywebapp          -- gen_context(system_u:object_r:mywebapp_exec_t,s0)

# Application base content and libraries
/var/www/mywebapp(/.*)?             gen_context(system_u:object_r:mywebapp_content_t,s0)

# Dynamic writeable storage (sessions, uploads, cache)
/var/www/mywebapp/storage(/.*)?     gen_context(system_u:object_r:mywebapp_rw_t,s0)

# Dedicated application logs
/var/log/mywebapp(/.*)?             gen_context(system_u:object_r:mywebapp_log_t,s0)

# Runtime PID and Unix domain socket
/run/mywebapp(/.*)?                 gen_context(system_u:object_r:mywebapp_rw_t,s0)

Production Systemd Unit Integration

Systemd natively interfaces with SELinux, allowing administrators to guarantee that a service spawns directly inside its confinement domain rather than inheriting ambient parent contexts. Below is the hardened systemd unit file configured for our custom web application.

# /etc/systemd/system/mywebapp.service
[Unit]
Description=High-Performance Custom Linux Web Service
After=network.target remote-fs.target postgresql.service redis.service
Wants=postgresql.service redis.service

[Service]
Type=simple
User=mywebapp
Group=mywebapp
WorkingDirectory=/var/www/mywebapp
ExecStart=/usr/local/bin/mywebapp --config /var/www/mywebapp/config.yaml
Restart=always
RestartSec=5s

# Explicit SELinux Context Transition
SELinuxContext=system_u:system_r:mywebapp_t:s0

# Standard Linux Sandboxing Defenses
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/www/mywebapp/storage /var/log/mywebapp /run/mywebapp
PrivateTmp=true
CapabilityBoundingSet=
AmbientCapabilities=

[Install]
WantedBy=multi-user.target

Compiling, Packaging, and Deploying the Custom Module

To compile the policy on an enterprise system (RHEL 9 / Rocky Linux 9 / AlmaLinux 9), install the development headers provided by selinux-policy-devel. The following automated deployment script compiles the definitions, registers the network port, and applies filesystem contexts.

#!/usr/bin/env bash
# build_and_deploy_selinux.sh - Autonomous SELinux Policy Builder
set -euo pipefail

MODULE_NAME="mywebapp"
PORT_NUMBER="8080"

echo "[*] Installing policy development prerequisites..."
dnf install -y selinux-policy-devel setools-console policycoreutils-python-utils

echo "[*] Compiling SELinux policy module: ${MODULE_NAME}..."
make -f /usr/share/selinux/devel/Makefile ${MODULE_NAME}.pp

echo "[*] Installing compiled policy package into kernel..."
semodule -i ${MODULE_NAME}.pp

echo "[*] Registering custom application network port (${PORT_NUMBER}/tcp)..."
if ! semanage port -l | grep -q "mywebapp_port_t.*${PORT_NUMBER}"; then
    semanage port -a -t mywebapp_port_t -p tcp ${PORT_NUMBER}
fi

echo "[*] Relabeling filesystem paths according to ${MODULE_NAME}.fc..."
restorecon -Rv /usr/local/bin/mywebapp /var/www/mywebapp /var/log/mywebapp /run/mywebapp

echo "[✓] SELinux policy successfully deployed and enforced."

Systematic AVC Denial Triage without Disabling Enforcement

When unexpected denials occur during initial application testing, modern administrators must avoid disabling SELinux globally. Instead, follow this structured diagnostic methodology:

1. Switch the Specific Domain to Permissive Mode: Rather than setting the entire node to permissive, isolate only the target domain: semanage permissive -a mywebapp_t. This ensures the rest of the operating system remains fully defended while your application runs without AVC blocks.
2. Inspect the Audit Telemetry: Query raw AVC records using ausearch -m avc -ts recent or generate human-readable explanations with sealert -a /var/log/audit/audit.log.
3. Audit Vector Verification: Examine whether the denial is caused by a missing file label (remediable via restorecon), an unassigned network port (remediable via semanage port), or an undocumented system capability.
4. Re-Enforce Confinement: Once adjustments are compiled into the .te file and loaded, remove permissive mode: semanage permissive -d mywebapp_t.

# Real-time AVC denial monitoring
ausearch -m avc -ts recent -i | grep mywebapp_t

# Check the active state of our custom domain
semodule -l | grep mywebapp
semanage permissive -l | grep mywebapp_t || echo "Enforcing"

# Verify process security context in production
ps -eZ | grep mywebapp

Frequently Asked Questions