Skip to content
CloudOps
Prompts Newsletter
All prompts
AI for DevOps Security & Hardening Difficulty: Intermediate ClaudeChatGPT

Sudoers & Systemd Services Review Prompt

AI review of /etc/sudoers (and /etc/sudoers.d/*) and systemd service unit files for privilege escalation, unsafe defaults, and hardening gaps.

Target user
Sysadmins, SREs, and security engineers auditing Linux privilege configs
Difficulty
Intermediate
Tools
Claude, ChatGPT

The prompt

You are a senior Linux security engineer who has audited sudoers and systemd configs after real privilege-escalation incidents. You know which configs look harmless and aren't.

Review the configs I share. Two passes:

### Pass 1: /etc/sudoers and /etc/sudoers.d/*

For each user, group, or rule, check:

1. **Scope of grant**
   - Any user with `ALL=(ALL:ALL) ALL` who doesn't strictly need full root?
   - Any rule using `NOPASSWD:` for commands that allow privilege escalation (e.g., `vi`, `less`, `find`, `awk`, `python`, `bash`, `sh`, `tee`, `cp`, `mv`)?
   - `Defaults env_keep += ...` adding env vars that could be abused (`LD_PRELOAD`, `PYTHONPATH`, etc.)?

2. **Command specificity**
   - Granular `Cmnd_Alias` definitions, or just `ALL`?
   - Paths to allowed commands fully qualified (`/usr/bin/systemctl`, not `systemctl`)?
   - Wildcards in command args that could be abused (e.g., `/usr/bin/cat /var/log/*` allows `/var/log/../etc/shadow` via tricks)?
   - Allowed commands that take arbitrary scripts as arguments (`bash`, `python -c`, etc.)?

3. **Logging & audit**
   - `Defaults logfile=/var/log/sudo.log` (or syslog) set?
   - `Defaults log_input,log_output` for sensitive operations?
   - `Defaults requiretty` set (where appropriate to your env)?
   - Banner / lecture configured?

4. **Order of precedence**
   - Files in `/etc/sudoers.d/` parsed alphabetically — does a later file override an earlier one in unexpected ways?

### Pass 2: systemd service unit files

For each service:

1. **User & privilege**
   - `User=` and `Group=` set to a non-root account where possible?
   - `DynamicUser=yes` for ephemeral services?
   - `NoNewPrivileges=yes`?
   - `CapabilityBoundingSet=` set to only required capabilities (empty when no caps needed)?
   - `AmbientCapabilities=` set explicitly?

2. **Filesystem isolation**
   - `ProtectSystem=strict` (or `full`)?
   - `ProtectHome=yes`?
   - `ReadOnlyPaths=` / `ReadWritePaths=` explicitly listed?
   - `PrivateTmp=yes`?
   - `PrivateDevices=yes`?

3. **Network isolation**
   - `PrivateNetwork=yes` if the service shouldn't have network access?
   - `RestrictAddressFamilies=AF_INET AF_INET6` (or whatever's needed)?
   - `IPAddressAllow=` / `IPAddressDeny=` if traffic should be restricted?

4. **Kernel & syscall hardening**
   - `SystemCallFilter=@system-service` or stricter?
   - `LockPersonality=yes`?
   - `MemoryDenyWriteExecute=yes` (where compatible)?
   - `RestrictNamespaces=yes`?
   - `RestrictRealtime=yes`?
   - `ProtectKernelTunables=yes`, `ProtectKernelModules=yes`, `ProtectKernelLogs=yes`?
   - `ProtectControlGroups=yes`?

5. **Restart & resilience**
   - `Restart=on-failure` (not `always`, which masks real bugs)?
   - `RestartSec=` set sensibly (not 0)?
   - `StartLimitBurst=` and `StartLimitInterval=` to prevent crashloop hammering?

For each finding: **severity**, **file:line**, **issue**, **fix** (config diff).

---

/etc/sudoers and /etc/sudoers.d/ contents:
```
[PASTE]
```

Systemd service units (paste one or more):
```ini
[PASTE]
```

Why this prompt works

Sudo and systemd are where privilege escalation paths hide. A NOPASSWD: /usr/bin/find looks innocuous until you realize find can exec arbitrary commands. A systemd service with User=appuser looks safe until you notice CapabilityBoundingSet= was never set and it inherits everything.

This prompt does both audits in one pass and produces actionable fixes.

How to use it

  1. Run sudo cat /etc/sudoers /etc/sudoers.d/* and paste sanitized output (remove user/host names if sensitive).
  2. Pick a representative systemd unit you want hardened (e.g., your app service). Paste its full content.
  3. Apply fixes via visudo -f <file> for sudoers, and systemctl edit <unit> for systemd overrides.

Helpful audit commands

# Effective sudo rules for a user
sudo -l -U <username>

# Which binaries can escalate via sudo
sudo -ll | grep -v '^Sudoers'

# systemd hardening score for a service
systemd-analyze security <service-name>.service

# Verify a unit file
systemd-analyze verify /etc/systemd/system/<unit>.service

Reference: hardened systemd template

[Unit]
Description=My App
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
ExecStart=/usr/bin/myapp
Restart=on-failure
RestartSec=5
StartLimitBurst=3
StartLimitInterval=60

NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
RestrictNamespaces=yes
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
SystemCallFilter=@system-service
SystemCallArchitectures=native
CapabilityBoundingSet=
AmbientCapabilities=
ReadWritePaths=/var/lib/myapp

[Install]
WantedBy=multi-user.target

Common sudoers anti-patterns this catches

  • ALL ALL=(ALL) NOPASSWD: ALL for non-admin users
  • NOPASSWD: /usr/bin/systemctl restart * — wildcards allow restarting anything
  • NOPASSWD: /usr/bin/vi — vi can spawn shells (!sh)
  • Defaults env_keep += "LD_PRELOAD" — privilege escalation via library injection
  • Rules in /etc/sudoers.d/91-zzz overriding earlier files unintentionally

Related prompts

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.