Privilege boundaries in scripts and configs

Why this area matters

Local privilege escalation turns a limited foothold — a web-server user, a CI job — into full control of the machine. On Linux the usual causes are configuration, not kernel bugs: setuid binaries, sudo rules that allow anything, world-writable scripts that root later runs, and predictable temp files (CWE-269, CWE-276, CWE-732). Windows has equivalents in service permissions and unquoted service paths.

Scanners flag chmod 777 wherever it appears, including on throwaway directories in tests. The file-permissions agent checks what the file is, who runs it and whether the permission actually crosses a privilege boundary.

What goes wrong in real applications

• Setuid and broad sudo

  Setuid helpers and sudo rules like ALL=(ALL) NOPASSWD: ALL let any process running as that user become root.

• Writable files run by privileged users

  Scripts, configs or binaries writable by everyone but executed by root or a service let any local user change what privileged code does.

• Predictable temp files and symlinks

  Fixed paths in /tmp opened by privileged code can be pre-created or redirected, causing it to overwrite files it shouldn't.

• Services running as root without need

  A service that runs as root makes every bug in it a root-level bug.

Sample: the risky pattern and the fix

#!/bin/sh
install -m 4755 bin/backup-helper /usr/local/bin/backup-helper
echo "deploy ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/deploy
install -m 666 config.yml /etc/acme/config.yml
cp hooks/nightly.sh /tmp/nightly.sh && chmod 777 /tmp/nightly.sh

#!/bin/sh
set -eu
install -m 0755 bin/backup-helper /usr/local/bin/backup-helper
echo "deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart acme" > /etc/sudoers.d/deploy
chmod 0440 /etc/sudoers.d/deploy
install -m 0640 -o root -g acme config.yml /etc/acme/config.yml
install -m 0750 -o root -g acme hooks/nightly.sh /usr/local/lib/acme/nightly.sh

The original installs a setuid-root helper, gives the deploy user unrestricted root through sudo, and leaves a config and a root-run script writable by every local user. The fix drops setuid, limits sudo to the one command the deploy user needs, and installs files owned by root with group-only access.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• chmod/install modes, umask and file ownership in scripts, Dockerfiles and packaging
• Setuid/setgid bits and sudoers entries committed to the repo
• Temp-file creation with fixed paths, and symlink-following writes
• systemd units and Windows service definitions running as root or SYSTEM without need
• Whether the file is a test fixture or a scratch directory (the main false-positive signal)

Scope and limits

• It reviews scripts and config in the repository; it doesn't log in to hosts, enumerate local permissions or test escalation paths.
• Kernel and OS vulnerabilities are out of scope — patch management isn't something a code review can see.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Privilege & file permissions — Checks file permissions, temp files, symlinks and unnecessary root.
• Container & Kubernetes — Checks Dockerfiles and Kubernetes manifests for root, privileged and host-level access.