Overview: Root Lock blocks kernel module loading with a latch: a kernel setting that, once switched on, stays on until the next reboot.
The latch is heartsuite-kernel-latch.service. It runs early in every Root Lock kernel boot, Setup Mode included, before the network is configured and before sshd starts. It first loads the netfilter modules the firewall needs. Then it sets kernel.modules_disabled=1, and kernel.kexec_load_disabled=1 where that node exists. From then until reboot, a later modprobe stays refused (init_module, finit_module, and delete_module). The latch script does not unload modules already in memory. The kernel setting does the blocking, not a Root Lock check.
HS_lockdown.sh writes the same settings again, where the node exists, in case the latch service is masked. OpenRC systems have no latch service and get those writes only when Lockdown is applied.
HeartSuite is not on yet while that oneshot runs, so the program allowlist is not what stops module loads in that window. This page is how you narrow kmod’s file grants before Lockdown seals the allowlist.
When no extra work is needed
If kmod has no directory grant under /lib/modules or /usr/lib/modules, you can skip the rest of this page.
When kmod is allowlisted
Some hardware configurations load drivers or filesystem modules at startup. The latch runs after udev’s initial device scan, systemd-modules-load.service, the binfmt_misc mount, and ufw.service (when enabled). Those early loads are that boot path and the latch’s own netfilter preload.
A kmod program that holds a directory grant on /lib/modules or /usr/lib/modules can load any module present in that tree. Narrow those grants to the module paths kmod needs. An allowlisted kmod with a directory read under /lib/modules can open module files that were never observed during Setup Mode. The latch’s own netfilter preload is a fixed list. File grants do not add to it.
Narrow file access before Lockdown
Do this before you type YES on Lockdown, because once Lockdown is active the allowlist entries are sealed and changing them takes a maintenance window.
When kmod’s startup activity appears in the File Access queue ([f]) during Setup Mode, approve individual .ko paths rather than directory-level access. Approving a directory grants read access to everything under it — including modules not present during observation.
If directory grants under /lib/modules are still present when you open Lockdown ([l]), seal prep auto-narrows them. That panel is advisory and does not ask for YES; pressing [m] there undoes the narrowing rather than opening Maintenance. Under Lockdown the same inventory is read-only.
Handle any grants left after auto-narrowing in Allowed ([a]) or File Access ([f]); the Dashboard, not a CLI, is the normal path.
After narrowing, reboot and confirm the machine starts with no unexpected kmod denials in the review queues. Then activate Lockdown ([l]).
What stays sealed after Lockdown
After Lockdown engages:
- Allowlist entries are sealed — kmod’s entry cannot be modified while Lockdown is active.
- Startup scripts are sealed — system-wide shell configuration, systemd unit directories, and cron. Attackers cannot insert scripts that would run before Lockdown re-engages on the next boot and expand kmod’s permissions.
After the latch, a later modprobe stays refused. The allowlist and kmod’s file grants are a separate control, and Lockdown seals them.
Per-user shell profile coverage
Lockdown seals system-wide shell configuration — /etc/profile, environment defaults, and cron — preventing an attacker from planting scripts that run at the next boot and expand kmod’s permissions before Lockdown re-engages. A script that widens kmod’s file grants still cannot load a module once the latch has run. Per-user profile files (~/.bash_profile, ~/.bash_login, ~/.profile, ~/.bashrc, ~/.inputrc) are not covered automatically because the correct set depends on your user configuration.
If specific user accounts need that coverage, do it in Setup Mode (before the first Lockdown, or after unseal). The Dashboard has no per-user profile picker, so edit the scripts: uncomment those users’ profile lines in HS_lockdown.sh and the matching reverse lines in HS_unlock.sh. Then lock down from Lockdown ([l]).