sudo Works Interactively but Fails Inside the Hardened CI Unit

The failure happens before sudo ever reads its policy.

sudo is a setuid-root binary; elevation depends on the kernel honouring the setuid bit at execve(). NoNewPrivileges=yes sets PR_SET_NO_NEW_PRIVS on the service process, and the kernel then refuses to grant any new privilege to that process or its children - including setuid. sudo starts with an effective UID equal to deploy, sees geteuid() != 0, and prints exactly that message.

So the sudoers syntax, the mode 0440, and visudo -cf were never in question: no policy lookup is attempted.

Proof, in order:

1. systemctl cat ci-agent.service and its drop-ins - confirm NoNewPrivileges=yes is actually in effect.
2. Reproduce outside the service: systemd-run --uid=deploy --property=NoNewPrivileges=yes /usr/bin/sudo -n /usr/bin/systemctl restart myapp fails; the same command without that property succeeds.
3. sudo -l as deploy interactively shows the rule matches, which isolates the environment rather than the policy.
4. journalctl -u ci-agent shows the same exit code with no sudo policy log line.

This is the classic 'validated the file, missed the sandbox' trap.

Preferred: keep every hardening flag and remove sudo from the path. systemctl restart myapp reaches PID 1 over D-Bus, where authorization is polkit's job, not setuid's. Add /etc/polkit-1/rules.d/50-deploy-myapp.rules granting org.freedesktop.systemd1.manage-units to deploy only when the looked-up unit equals myapp.service, plus the matching action in a .policy file. The agent then runs plain systemctl restart myapp. Least privilege: one verb on one unit, no root shell, no setuid dependency, and the unit keeps NoNewPrivileges=yes.

Acceptable: a narrow privileged helper. A root-owned wrapper with a hard-coded unit name, executed by a dedicated unit that deploy is allowed to start - or a sudo rule after deliberately setting NoNewPrivileges=no on that one unit.

Avoid: clearing NoNewPrivileges on the whole agent. It weakens the entire unit, including any binary the agent executes from a workspace it can write, and re-opens sudo as a privilege-escalation path. You would be trading a real sandbox boundary for one convenience command.

In all cases keep the sudoers entry exact-match - no systemctl *, no wildcards, no ALL on the command - and verify with sudo -ll that the resolved command and arguments match what the agent actually invokes.

1. Reproduce the failure under the real unit before changing anything: systemd-run --unit=ci-test --uid=deploy -p NoNewPrivileges=yes /usr/bin/sudo -n /usr/bin/systemctl restart myapp → expect exit 1 with the same message.
2. Apply the polkit rule, systemctl restart polkit, then run the same path without sudo: systemd-run --uid=deploy -p NoNewPrivileges=yes /usr/bin/systemctl restart myapp → expect success, and journalctl -u polkit to show an authorization granted for myapp.service.
3. Negative tests. The same user must fail on systemctl restart sshd, systemctl stop myapp, and a direct busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit nginx.service s replace. If any succeeds, the rule is too broad - usually a missing unit check.
4. Confirm the sandbox is intact: systemd-analyze security ci-agent.service still reports NoNewPrivileges=yes.
5. Audit trail: one attributable entry per deployment across journalctl -u ci-agent -u polkit.

Residual risk: polkit rule ordering and interaction with distro defaults - an earlier return polkit.Result.NO can override your later allow, and a vendor update can ship a rule that weakens yours. The negative tests are the control; re-run them after package upgrades, and keep the rule file under configuration management rather than hand-edited on the host.