Skip to main content

Server lockdown

The other layers stop a stranger's words from becoming actions. This layer assumes something got through anyway. It limits what any program on the box can do, so a hijacked agent still can't take over the machine.

Where you see it​

You don't. It's the floor under everything else. The only sign of it is that agents ask for a few things (like "clear the box" or "apply the changes") in a roundabout way, through a request file. That's the lockdown working.

The service locks​

Every agent service on the box starts with a file called hardening.conf (the lock settings). It turns on these locks:

LockWhat it means in plain words
NoNewPrivilegesThe program can never raise its own power, even by running a tool that normally could.
ProtectSystem=fullThe system folders are read-only to it.
PrivateTmpIt gets its own private scratch folder, hidden from other programs.
ProtectKernelTunables, ProtectKernelModules, ProtectControlGroupsIt can't change the core settings of the operating system.
RestrictSUIDSGIDIt can't create files that run with extra power.

The chat page and Discord are open to the internet. NoNewPrivileges is the main thing keeping a chat message from owning the machine.

The narrow root list​

Root (full control of the machine) is sometimes needed. Two jobs need it: clearing the box's memory swap, and restarting a service that died. So the agent's account may run exactly these as root, with no password:

  • one named script, box-fresh (clears swap)
  • systemctl restart for seven named services, each spelled out: the login door, the chat page, the Discord agent, the tool door, the two WhatsApp services, and the web server

That's the whole list. It is not "run anything as root."

Why every name is spelled out. A wildcard like "restart anything" sounds harmless. It isn't. A service name is just a string, and an attacker can choose strings. With a wildcard, a crafted service could be used to run almost anything as root. So each service is named, and adding one more means editing this file on purpose. As the file says, "that friction is the point." It also allows only restart, never stop or disable, since the job is to bring things back up.

What happens, step by step​

The service locks create a puzzle. NoNewPrivileges blocks the tool that grants root, even for commands on the list. So how does the chat ask for root work? Through a separate helper.

  1. The owner tells an agent in chat, "Apply the changes."
  2. The agent can't become root. It writes a plain file, a request file, with a one-line reason.
  3. A small helper that runs as root, apply-watcher.sh, checks every minute. If there's no request file, it does nothing and exits.
  4. If the file is there, it runs exactly one command: the one that copies files already saved in git into place.
  5. Nothing in the request file can change what runs. Its words are used only as a log line.

A second helper, fresh-watcher.sh, works the same way for clearing swap. At worst, a hostile chat message could make it clear swap. It could already cause that by asking the owner.

What powers it​

PartWhat it does
hardening.confThe lock settings every agent service starts with.
sudoers-box-freshThe short, exact list of root commands.
apply-watcher.shRoot helper. Applies saved changes when a request file appears.
fresh-watcher.shRoot helper. Clears swap when a request file appears.
apparmor-bwrapLets one sandbox tool build its sandbox, and nothing more.

Why it works this way​

This is defense in depth (walls behind walls). Even if the quarantine, the send guard, and the memory guard all failed at once, these locks cap the damage. They know nothing about email or injection. They just shrink what any program could do.

Connected to​