jschoubben
f30089c288
The review of 2026-10-09: an unknown account and sudo that could not be asked were answered not root, and only NOPASSWD on ALL counted, though NOPASSWD on systemctl, tee, bash or pacman reaches root as surely, and a password the person typed is kept by sudo for minutes. Any rule now counts, as the node-engine's own judge of an agent account does (ADR 0266); what cannot be judged fails the answer. The bundle built in the module's directory is removed and ignored.
sudo
Privilege escalation as a module (novox/hq to-be 42 Phase 1, research 027).
What it owns
- The
sudopackage. /etc/sudoers.d/10-mesh-operator, root's, mode 0440, written whole:<operator account> ALL=(ALL:ALL) NOPASSWD: ALL.
That one line is what the mesh's acting tools assume: the packet filter, the service manager and the
intrusion prevention tools act through sudo -n as the operator account (to-be 38 WP4). Before this
module, nothing declared it. Each machine said it in its own line in /etc/sudoers, set by hand: a
wheel group rule on two machines, the account by name on the other two.
A sudoers file that does not parse locks sudo for every account. The manifest test renders the drop-in
for several account names and runs visudo -cf on each. It skips that check where visudo is not
installed.
What it improves
- The escalation is declared once, the same on every machine, and readable through its tools.
labno longer declares thesudopackage (novox/hq ADR 0207: a component's package belongs to one module). Lab's tools still rely on sudo, and this module provides it on every machine.
What it leaves found
/etc/sudoersitself: itsrootline, the hand-set grants (%wheel, the account by name,%sudo), and its@includedir. They are redundant beside the drop-in, and removing them is a person's act on each machine (ADR 0182).sudo_checkshows each grant and the one that decides.- Every other file in
/etc/sudoers.d.
Tools
| tool | answers | |
|---|---|---|
sudo_rules |
r | sudo -n -l parsed: the defaults, and each rule with its run-as, tags and commands; passwordless_all |
sudo_check |
r | whether sudo -n works, every grant naming the account, its groups or ALL in the order sudo reads them, the one that decides, and whether the module's drop-in is present |
sudo_drop_ins |
r | /etc/sudoers.d with owner, mode, size, whether sudo reads each file (name, owner, mode), whether each parses, and whether the whole parses |
The tools change nothing. They read root-only files through sudo -n, and a refusal is an answer, not
an empty list.