Hardening Linux Services: Dedicated Service Users

Running services as root is a significant security risk. If a service is compromised, the attacker gains full control over the entire system. To prevent this, we use the Principle of Least Privilege by creating dedicated system users that only have access to what they absolutely need.

Core Concept

The goal is to create a “Service User” that:

1. Has no login capabilities.
2. Has no home directory.
3. Can only access its specific application files.
4. Runs within a hardened systemd sandbox.

Implementation Guide

sudo adduser --system --no-create-home --shell /usr/sbin/nologin <service-or-user-name>

sudo groupadd <service-or-user-name>
sudo usermod -g <service-or-user-name> <service-or-user-name>

sudo mkdir -p /var/lib/<service-or-user-name>  # For data/state
sudo mkdir -p /etc/<service-or-user-name       # For configuration

sudo chown -R <service-or-user-name>:<service-or-user-name> /var/lib/<service-or-user-name>
sudo chown -R <service-or-user-name>:<service-or-user-name> /etc/<service-or-user-name>
sudo chmod 750 /var/lib/<service-or-user-name>

[Unit]
Description=My Service
 
[Service]
User=<service-or-user-name>
Group=<service-or-user-name>
ExecStart=/usr/bin/my-binary
Restart=always

[Service]
# File system protection
ProtectSystem=full
ProtectHome=yes
PrivateTmp=yes
 
# Privilege protection
NoNewPrivileges=yes
RestrictRealtime=yes

# Network restriction (e.g., allow only local communication)
IPAddressAllow=127.0.0.1
IPAddressDeny=any
 
# Resource limits
MemoryMax=512M
TasksMax=50

Best Practices

Even with a dedicated user, remember these two rules:

• Package Management: Always use root (via apt or dnf) to install software. Never change ownership of system binaries to your service user.
• Minimal Write Access: If a service only needs to read its config, use chown root:service-name and chmod 640 for files in /etc/service-name.

Result

Each service now runs as a separate, non-loggable, minimally privileged user. If a vulnerability is exploited, the attacker remains trapped within the service’s specific directory and cannot access system-wide files or other users’ data.

Note for External Collaborators

A final important note:
Due to this strict isolation, regular users (e.g., developers without root privileges) will not be able to view or edit the service’s files. If you need to grant an external user specific read or write permissions to these directories without compromising the service user’s security, standard POSIX permissions reach their limits.

In this case, the guide on Linux ACLs (Access Control Lists) will be particularly relevant, as it allows you to assign fine-grained permissions for additional users without changing the primary ownership.