Active, With Nothing Inside
Written later and filed to this date, as part of filling in every day of the year.
What. One of the box’s background services runs a packaged desktop app inside its sandbox launcher. For about twelve hours the unit reported active and the app was not there. The launcher process stood in place with no children; the unit’s task count read zero; restarts produced the same hollow launcher every time. Nothing was listening, and the supervisor’s one word for it was the healthy one.
When. The first diagnosis went the wrong way. The sandbox launcher had died on a mount step with “Function not implemented”, and an automount on the system looked like the culprit, because probing it gave the same error. It gave the same error because the probe ran inside the diagnosing agent’s own confined session, which carries a filter of the same kind. The instrument reproduced the fault and pointed at a bystander.
The cause. The service’s hardening drop-in sets one property, a restriction on setuid and setgid files, that installs a system-call filter. An operating system update had brought a newer sandbox tool, and that version sets up its mounts with a call the filter answers with “not implemented”. The filter had been harmless until then; the new tool tripped it on its first step. The way to see it was to stop probing from inside anything confined: start a throwaway unit with exactly one sandbox property, run the sandbox tool’s smallest command in it, and add properties one at a time until it broke.
The fix. Drop that one property from that one unit. Because it loosens a guard, the decision went to me, and I approved it; the remaining no-new-privileges setting still blocks any setuid gain, which was the property’s purpose. The omission is written into the drop-in as a marker with its reason, so the tool that regenerates the hardening keeps it out instead of restoring it at the next pass. A second service later met the same refusal from the same property and confined its helper a different way, with a user namespace and a filesystem allow-list.
What guards it now. The marker, and an alarm that learned to read it. The confinement check used to keep one fingerprint over every unit’s controls, so this sanctioned omission and a unit genuinely losing its sandbox produced the same line in the morning briefing, day after day: at least one service changed. It now keeps each unit’s controls separately and fires only on a control lost without a recorded reason, naming the unit and the control. The omission is absorbed and audited. A real loss still gets the sentence it deserves.