56. Restart after hardening

Some hardening changes take effect only after the host restarts (for example SEHOP, LSA protection, memory integrity and Credential Guard on Windows). Lawliet applies them, holds them as reboot pending, and validates them on the host's next boot: the agent reports which boot it is in, and a different boot identity means the host has restarted (26).

Lawliet never restarts a host on its own. The Restart needed panel on the Hardening page shows which hosts wait for a restart. A person can ask Lawliet to restart one host or every pending host; a second administrator approves it; the host warns its logged-in users and restarts after the delay chosen. Until the host has restarted, a review-queue item reminds you.

In 1.5.15.2.s only Windows hardening controls are marked as needing a restart. A Linux host therefore never appears in Restart needed, and a restart request for one is refused with "Nothing on this host waits for a restart". Linux hardening controls get restart handling in a later release; the Linux rows below describe what the agent does then.

56.1 What the panel shows#

Hardening > Restart needed lists every host with at least one applied change that waits for a restart:

States of a restart request:

Under Recent restarts (24 h) the panel keeps hosts that no longer wait, with the result of their restart. A host whose agent cannot report restarts (an agent older than 2.1.10.s) says so: re-scan it after it restarts.

56.2 Procedure: restart a host#

You need Restart hosts after hardening (Appendix B). The request is a critical action (Restart a host after hardening): while dual control is on it waits for a second administrator.

1. Open Hardening. In Restart needed, choose the delay in Warn users, then restart after (default 5 minutes; from no warning up to 60 minutes).
2. Click Restart now on a host, or Restart all pending (N) for every host that can be restarted now. Hosts that cannot (offline, macOS, the Lawliet server) are left out.
3. Read the confirmation: the hosts, the delay and the message users will see. Click Request restart. When asked, give the reason for the approver.
4. A second administrator approves it in Approvals (15.6); you then run it from Approvals > My requests. The person who requested it cannot approve it.
5. The host shows users warned with its restart time, then restarting, then restarted - validating and restarted and validated.

Logged-in users see: "This computer will restart in N minutes for security changes by your IT team. Save your work." (with no delay: "This computer will restart now ..."). The request is all or nothing: if any listed host cannot be restarted, nothing is requested and each refused host is named with the reason, before anything is sent for approval.

56.3 Procedure: cancel a restart#

1. In Restart needed, click Cancel restart on the host (shown while the restart is requested, users warned, or restarting).
2. If the host had not picked the request up yet, it is withdrawn and never reaches the host. Otherwise a cancel is sent; the chip shows cancelling, then cancelled once the host confirms.

Cancelling needs Restart hosts after hardening and one signature: it stops a restart, it never starts one. The changes keep waiting; restart the host later, from here or by hand.

56.4 What is never restarted#

A restart is refused, with the reason shown on the host and in the refusal, when:

• the host is offline - a restart is never queued for later; request it again when it is back;
• the host runs macOS - not supported; restart it by hand (the changes are validated on its next boot);
• nothing on the host waits for a restart, or a restart is already requested for it;
• the host is the Lawliet server's own agent: pinned in the never-touch list (48), or its address or name matches the server's. Restart the server by hand in a maintenance window;
• Lawliet does not yet know which host is its own server: every host is refused until the server's agent is pinned in the never-touch list, or administrators confirm (four-eyes) that no agent runs on the server (48). On a Docker install the server cannot recognise its own host from inside the container, so do this once after installing;
• the host is on the operator never-touch list, or that list cannot be read.

A sandbox account sees and restarts sandbox hosts only, and nothing is ever sent to a sandbox host.

56.5 The review-queue reminder#

When a host has waited more than an hour, the review queue gets one item for it, Restart <host>: N hardening change(s) wait for it, due 24 hours after the change first waited (21). The item closes by itself when the host reports a new boot (checked on every agent heartbeat and every five minutes). Restarting the host by hand closes it the same way.

56.6 What the host runs#

The request reaches the host as a signed agent task (replay-protected, valid for 10 minutes). The agent re-checks the delay and the message, then runs, without a shell:

The agent reports the restart as scheduled before it happens. The restart time the console shows is the server's: when that answer arrived, plus the delay. Approvers read the host names of the request; the server checks them against the hosts before the request is filed and again when it runs.