Information
The NGINX master process typically runs as root to bind to privileged ports and manage resources, but it spawns worker processes to handle the actual client traffic. The user directive in the main configuration designates the operating system account under which these worker processes run.
Running worker processes under a non-privileged, dedicated service account limits the damage an attacker can cause in the event the NGINX process is compromised. This account should be exclusively dedicated to NGINX, have no login capabilities, and possess no elevated system privileges.
If an attacker successfully exploits a vulnerability in a worker process (e.g., via a buffer overflow or Remote Code Execution), they inherit the permissions of the user account running that process. Using a privileged account like root significantly increases the risk of lateral movement. A dedicated, locked-down service account ensures that an attacker cannot access other services, modify sensitive system files, or easily escalate privileges, effectively reducing the impact of the compromise.
Solution
1. Create/Harden User (if missing):
If no user exists, create a system user with a no login shell:
useradd -r -d /var/cache/nginx -s /sbin/nologin nginx
2. Configure NGINX:
Set the user directive in the main context of nginx.conf :
user nginx;
3. Lock User Account:
Ensure the account cannot be used for login:
usermod -s /sbin/nologin nginx
usermod -L nginx
Impact:
Changing the NGINX user requires that ownership and permissions for all runtime directories (logs, caches, PID files) are updated to match the new account. Incorrect permissions will prevent NGINX from starting or writing necessary logs. Additionally, the dedicated user must remain strictly unprivileged; adding it to groups like sudo or wheel would negate the security benefit.