jochen
f015aba34a
Three modules' tools act through `sudo -n` and nothing declared that the account may; each machine said so in a hand-set line in /etc/sudoers. The module owns the package and /etc/sudoers.d/10-mesh-operator (0440), checked by visudo in its manifest test, and serves sudo_rules, sudo_check and sudo_drop_ins from a Go bundle. lab stops declaring the sudo package, which would collide with this module on the node that runs both (hq ADR 0207, to-be 42 Phase 1).
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.