[lr00rl]

Keeps the enrollment token off sudo's command line. Base: integration at 75e54b2. Not merged, tagged or released. lattice-server #212 (LatticeNet/lattice-server#212) vendors this head.

The problem

Run without root, the installer re-executed itself as exec sudo LATTICE_NODE_TOKEN=<token> ... sh install.sh. sudo stays alive for the whole install, so any local user could read the token in ps for as long as it ran. sudo also writes its command line to its log (auth.log or journald, or a sudo logfile), where the old form left LATTICE_NODE_TOKEN=<token>.

The fix

The token goes to the root child in a file. The non-root parent:

• makes a 0700 directory with mktemp -d under TMPDIR;
• writes token into it under umask 077;
• passes only the path to sudo, as LATTICE_NODE_TOKEN_FILE.

The parent no longer execs sudo. It removes the directory when sudo returns, fails or is interrupted (EXIT, plus HUP, INT and TERM with 129, 130 and 143). It refuses a TMPDIR every user can write to without the sticky bit, before sudo runs, following a symlinked TMPDIR to its target. A file works whatever sudoers keeps or resets of the environment, which --preserve-env does not.

The root child reads only a file the re-exec could have made:

• in a directory that is not a link, mode 0700, owned by SUDO_UID (0 without sudo);
• a regular file, not a link, with exactly one link, mode 0600 and the same owner. An ACL is refused with its own message.

Anything else dies before any download. The child reads the token into a variable, removes the file, and removes the directory only if that leaves it empty. It never removes a path it was handed.

Tests

scripts/test-install-integrity.sh records the fake sudo's command line and fails when the token appears on it. Against the installer at 75e54b2 it fails with exactly that message. It also checks:

• that the re-exec hands over a token file;
• that the token reaches the service definition;
• that no token file outlives an install or a sudo that fails like a wrong password;
• that the child refuses a symlink, a 0644 file, a hard-linked file, a file in a 0755 directory, and a directory owned by another uid, while a refused file is left in place;
• that a 0777 TMPDIR is refused before sudo runs and before any file is written.

Local, all pass: sh scripts/test-install-integrity.sh and sh scripts/check-release-workflow.sh under macOS /bin/sh and dash, and in debian:bookworm (dash) and alpine:3.20 (busybox ash) as uid 1000.

Review

security-reviewer on 5cea729: no Critical or High. The token no longer reaches argv on any installer path. A third user polling ps every 2 ms during a sudo install never saw it.

Fixed in d5d79c8 and f7deddc, from its Lows:

• a swap between the checks and the read (now a private directory; a TMPDIR writable by every user without the sticky bit is refused);
• the link count;
• the misleading message on an ACL, at the file and at the directory;
• the signal exit codes.

Not changed here:

• Medium, the enrollment command. env LATTICE_NODE_TOKEN=... ./lattice-agent-install.sh shows the token in env's argv for about a millisecond, and it lands in shell history and in any wrapper's argv (ssh host '<cmd>', cloud-init). The fix needs a product decision: a single-use enrollment code exchanged by the installer, or a separate no-echo prompt. It is reported to the operator.
• Low: a kill -9 of the parent during the password prompt leaves the token file behind, now inside a 0700 directory.

Re-checks of d5d79c8 and f7deddc: nothing at Critical, High or Medium. The reviewer ran the installer through sudo on debian:bookworm with several TMPDIRs:

• refused: 0777 (the rename attack can no longer start), 0776, and a symlink to a 0777 directory;
• accepted: 1777, a private 0700 directory, and the default /tmp;
• a default ACL now gets the ACL message.

Left as is, on the reviewer's advice: a group-writable TMPDIR without the sticky bit is accepted. It needs the user to choose such a directory, and its worst effect is a wrong token sent to the real server.