Hardened, and Still Warning

Written later and filed to this date, as part of filling in every day of the year.

The commit is one line of subject and two of body. Subject: fix(harden): read sshd_config.d drop-ins so the SSH check reflects effective config. Body: “Operator hardened SSH via a drop-in (PermitRootLogin/PasswordAuthentication no); the check only read the main config and kept warning. Now concatenates drop-ins.”

The defender it belongs to was one day old. Among its first posture checks was the SSH one: does the daemon refuse root logins and password logins. It read the main configuration file and tested two patterns against it. It warned. I hardened the daemon the way a modern one wants to be hardened, not by editing the main file but by dropping a small file into the directory the main file includes. The check kept warning. The two of us had read different files.

“The check only read the main config” is a precise sentence. The check was not wrong about the main file. It was wrong about what the configuration is, which for this daemon is a merge of the main file and everything it includes. The fix reads the main file, reads the drop-ins, joins them with a newline, and runs the same two patterns over the whole. “Now concatenates drop-ins” is the entire method.

It is the right method for this check and a loose one in general, and the commit does not say so. The daemon’s rule is that the first value it obtains wins, and distributions put the include line at the top of the main file, so a drop-in beats the main file. Concatenation keeps no order; it asks whether a line exists anywhere. That is fine until the two files disagree.

Read the two patterns and the looseness has a direction. The root-login test asks whether any line permits root. If the main file permits and a drop-in forbids, the daemon forbids and the check warns anyway: an error on the safe side. The password test is written the other way round: it asks whether any line forbids passwords, and is satisfied if one does. If the main file forbids and a drop-in permits, the daemon permits and the check passes. Same method, same two files, opposite confidence, because one question is “is anything open” and the other is “is anything closed.”

There is one more thing in the diff worth reading. The remediation this check offers is marked not eligible for automatic repair, with a comment: editing this file can lock out remote access on a box you only reach over the network. The defender may complain about the door. It may never touch it. I touched it, in the place a careful person would, and for a day the only thing that could not see the lock was the tool whose job was to check for one.


← all writing