The Health Check That Runs as Root

Choose the Docker socket, not the kernel exploit. www-data is in a group that can read /var/run/docker.sock, which is root-equivalent. Verify with docker version and docker ps; if the daemon answers, use a minimal, non-persistent container: docker run --rm -v /:/host:ro alpine cat /host/etc/shadow. The read-only mount and --rm mean you do not modify the host and do not leave a container. If the image is not present, inspect docker images for an existing image rather than pulling from the internet, which may be blocked and noisy. This path avoids the kernel panic risk the client explicitly flagged and does not require a reboot. The sudo script is tempting because of the relative curl and tar calls, but sudo's secure_path usually resets PATH; do not assume a hijack works. Check sudo -l for SETENV and sudo -V for secure_path before attempting one. The Docker path is cleaner, reversible, and gives direct read access to /etc/shadow.

Fallback order: (1) re-check the sudo entry for SETENV; if present, run sudo PATH=/var/www/html:$PATH /opt/ops/healthcheck.sh and place a malicious curl in the current directory. Only do this if sudo -l shows SETENV and the script's relative command resolves through PATH. (2) Check whether /var/backups is writable by www-data or whether the tar destination can be influenced; as written it cannot. (3) Look for group-writable files in root-owned cron jobs or systemd timers, but do not create persistence. (4) Kernel exploit only with written client approval. Decide by testing preconditions with read-only commands: sudo -l, ls -ld, find /etc/cron* -writable, systemctl list-timers. Avoid running the sudo script repeatedly, because each invocation may create a backup file and alert operations. If none of the safe paths work, stop and report the Docker socket exposure as the finding; it is still a critical privilege-escalation risk even if you do not exploit it.

Refuse the kernel exploit and any persistence. The client said no kernel exploits unless approved because a prior panic took down a production pool; a 5.15 local privilege-escalation exploit has a nonzero crash risk, and the host is one of three behind a load balancer. Refuse to add a user, SSH key, cron job, or systemd unit, because persistence is out of scope and would survive cleanup. Refuse to modify /etc/shadow or the backup destination, because the task is proof of read access, not data-integrity testing. The Docker socket path does start a container, which is a change, but it is ephemeral and read-only; still, note it in the report and clean up. The professional judgement is to preserve availability and the evidence chain over demonstrating the most powerful exploit.