FAQs

A: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite controls all three per program — not per user, per program. Unlike anti-malware tools that look for signatures or suspicious behavior, Root Lock by HeartSuite requires every execution, file access, and network connection to be explicitly approved through the Dashboard’s review queues; in Lockdown, anything not approved is blocked. Because enforcement happens inside the kernel itself, it cannot be circumvented by any program or user, including root.

A: Root Lock by HeartSuite fits systems where the same programs do the same jobs, day after day — production servers with defined stacks, closed appliances and embedded devices, regulated workstations, build and CI infrastructure, and AI agent sandboxes inside per-task virtual machines. Containers fit as OCI images built and run on a separate host, with Root Lock by HeartSuite protecting the fixed-workload hosts around them — see the container reference architecture. Running a shared-kernel container runtime (Docker, containerd, Podman) directly on a host running the HeartSuite kernel is not a fit by design. The overlay filesystem and user namespaces are the privilege-escalation primitives the HeartSuite kernel deliberately omits — they are the attack surface, path to root, and vulnerability the design removes.

It is also not a fit for hosts that run eBPF-based tools like Falco, Cilium, or Tetragon; the BPF syscall is omitted for the same reason. See Deployment Scenarios for the full breakdown.

A: Yes. Each host runs the Root Lock by HeartSuite kernel with the same allowlist installed locally — no HeartSuite-provided central policy server or cloud dependency for enforcement or distribution. The same allowlist configuration (curated as policy-as-code or in your CMDB) can be distributed to any number of hosts by your existing automation (Ansible, Terraform + GitOps, Puppet, custom scripts, ServiceNow-driven workflows). Production deployments run Root Lock by HeartSuite across hundreds or thousands of nodes, all enforcing the same approved-programs policy. Fleet-wide event correlation, policy reconciliation, and compliance reporting are handled by your SIEM and control planes alongside Root Lock by HeartSuite — see How Root Lock by HeartSuite Compares and Central Policy Management and External Control.

A: Root Lock by HeartSuite replaces these tools on the preventive-enforcement dimension. Each of them can be disabled by an attacker who already has root — Falco agents can be killed, BPF programs unloaded, SELinux set permissive, AppArmor profiles detached, gVisor processes compromised, EDR drivers tampered with. Root Lock by HeartSuite has no agent to kill and no module to unload, and under Lockdown even root cannot change the allowlist at runtime. See How Root Lock by HeartSuite Compares for a side-by-side table including how each can be disabled and how Root Lock by HeartSuite can itself be circumvented (physical presence — keyboard and monitor, serial port, or cloud serial console — only). For a detailed SELinux comparison, see “How does Root Lock by HeartSuite compare to SELinux specifically?” below.

A: SELinux is a strong MAC framework — it confines processes using labels, enforces type-based file access controls, and limits capability use across the system. For organizations that maintain SELinux policy (refpolicy or targeted), it provides fine-grained control that Root Lock by HeartSuite does not replicate; SELinux’s domain transitions and per-service profiles are deliberate capabilities, not gaps.

The limitation is the trust boundary. Root with the right capability can set SELinux to permissive mode, reload a relaxed policy, or edit policy files directly. If the system is compromised before SELinux policy is fully hardened, the attacker has the same access as any root process and can dismantle the policy from there.

Root Lock by HeartSuite’s distinction is where enforcement is anchored. Under Lockdown, the allowlist is sealed at the filesystem level (chattr +i) and the HeartSuite kernel refuses to lift that seal at runtime — by any process, including root. There is no remote path to disable enforcement; modifying the allowlist requires booting the maintenance kernel, which requires physical presence — a keyboard and monitor, serial port, or your cloud provider’s serial console.

The two are not mutually exclusive. SELinux’s domain transitions and distribution-shipped per-application profiles add policy depth Root Lock by HeartSuite does not provide; Root Lock by HeartSuite adds the sealed boundary SELinux does not. See How Root Lock by HeartSuite Compares for the full side-by-side.

A: Root Lock by HeartSuite replaces the preventive-enforcement layer of the following tool categories. Whether you can remove a product entirely depends on whether you were running it purely for prevention, or also for telemetry and response.

Can remove or reduce:

• Commercial eBPF enforcement tools (Sysdig Secure, commercial Falco, Cilium Tetragon): enforcement is covered by the allowlist, and the BPF syscall is deliberately absent from the HeartSuite kernel by design (it is one of the privilege-escalation primitives that would supply attack surface and bypass paths). These tools cannot run on it anyway. OSS Falco carries no licensing cost but does carry ongoing rule-tuning overhead that goes away.
• gVisor: if used solely to protect workloads from root-level compromise inside a VM or microVM, Root Lock by HeartSuite is a direct replacement as the guest kernel.
• AppArmor / SELinux: no licensing cost, but the policy-authoring and drift-management overhead is replaced by observation-driven allowlist setup. See Security as Economics for the full comparison.
• The blocking dimension of Linux EDR (CrowdStrike Falcon, SentinelOne, MDE): prevention is replaced. Telemetry, behavioural analytics, and SOC console are not. Some vendors offer lighter-tier pricing once the workload prevention layer moves to Root Lock by HeartSuite.

Cannot remove:

• SIEM, NDR, vulnerability scanners, and HIDS/FIM — these answer questions Root Lock by HeartSuite does not: fleet correlation, traffic analysis, compliance reporting, and patch prioritisation. See “Does Root Lock by HeartSuite replace my SIEM, NDR, or vulnerability scanner?” below.

A: No. Root Lock by HeartSuite enforces at the kernel level on each host individually — it does not correlate events across a fleet, ingest external data, or produce compliance reports across a fleet on its own. (The same allowlist can be distributed to any number of hosts by your automation; see the FAQ above: “Can I use the same allowlist across a fleet or Kubernetes cluster?”) SIEM (Splunk, Sentinel, Elastic), NDR (Darktrace, ExtraHop), vulnerability management (Nessus, Qualys, Wiz), and HIDS/FIM (OSSEC, Wazuh, AIDE) answer fleet-wide, telemetry, and compliance questions that Root Lock by HeartSuite does not address. Run Root Lock by HeartSuite alongside them — it reduces the volume of events those products have to reason about by making a class of attacks impossible rather than merely visible. Root Lock by HeartSuite’s syslog streams, JSONL approval log, status.json, and webhook are designed inputs for your SIEM and control planes. See How Root Lock by HeartSuite Compares and Central Policy Management and External Control.

A: Many security products — including Falco, Cilium Tetragon, and CrowdStrike Falcon on Linux — rely on eBPF filters or user-space agents running as processes within the same OS as the programs they are meant to protect. Malware with sufficient privileges can disable, bypass, or unload them. Root Lock by HeartSuite’s enforcement is compiled into the kernel itself. There is no agent to kill, no filter to detach, and no module to unload. If the Root Lock by HeartSuite kernel is running, blocking is active. This is the difference between a lock on the door and a guard standing next to it.

A: Lockdown makes all allowlist entries and configuration files immutable at the filesystem level, then disables the ability to change immutability flags at the kernel level. This means not even root can modify, delete, or add allowlist entries while Lockdown is active — the kernel itself prevents it. To make changes, the Dashboard’s Maintenance ([m]) guides you through a 3-step process that includes booting the maintenance kernel to remove the immutable flags. The Dashboard confirms Lockdown status after every reboot.

A: x86 (64-bit) Linux. Validated in release testing: Debian 12/13, Ubuntu 24.04, Rocky 9.7, Fedora 41, CentOS Stream 9, Alpine 3.21. Supported without a specific gate run: Debian 11, Ubuntu-derived, Alpine 3.x. RPM enterprise (RHEL, AlmaLinux, SLES): RHEL-compatible — validate on your subscribed minor before production. Root Lock by HeartSuite ships two HeartSuite kernel lines: 6.18 (primary) and 5.19 (legacy). Full matrix: Distro Compatibility.

A: Download the tar file from heartsecsuite.com — the download form is on the website; direct wget links are not provided.

A: Yes. Email support@heartsecsuite.com or visit the tech support page on heartsecsuite.com.

A: For product bugs, email support@heartsecsuite.com with your Root Lock by HeartSuite version, kernel version (uname -r), the protection state shown at the top of your Dashboard, and steps to reproduce. For documentation corrections, open an issue on heartsuite-docs. For security vulnerabilities, email support@heartsecsuite.com for responsible disclosure — do not use public issue trackers.

A: Yes. Every time a file in a configured directory is modified, Root Lock by HeartSuite automatically creates a new versioned backup with a timestamp and file size. Under Lockdown, the kernel itself blocks any program (including root) from reaching the backup files — so even if an attacker compromises an approved program, the previous versions remain intact. Versions are never automatically deleted. Use the Dashboard’s Backup ([b]) to add or remove directories, browse version history, and restore any previous version of a file.

A: No. Most security products generate high volumes of alerts because they flag suspicious patterns — leading to alert fatigue where real threats get lost in the noise. Root Lock by HeartSuite only alerts on genuinely unauthorized activity: a program attempting to execute without approval, or an outbound connection to an unapproved destination. Events are deduplicated and batched in 5-minute windows, with an hourly cap on email alerts. In Lockdown with a complete allowlist, alerts are rare — because the allowlist already covers all legitimate activity. Configure alerts through the Dashboard’s Alert Settings ([e]) (email, syslog, or webhook).

A: Lockdown requires an active subscription, all review queues to be cleared, and alert settings to be configured. Setup Mode logs activity without blocking — you can observe your workload, but blocking is not active. The Dashboard presents a precondition checklist before activation.

A: Yes. Allowlist the SSH program and the IP addresses you connect from — remote access works the same as any other approved program.

A: The Dashboard is how you manage Root Lock by HeartSuite. It shows your current mode (Setup or Lockdown), progress through each setup phase, pending or denied counts, and a Suggested Next Step that tells you exactly what to do next. The indicator at the top confirms the current protection state at a glance. The Dashboard appears automatically on first login.

A: The Dashboard walks you through seven phases, from verifying your installation to activating full protection. Each phase focuses on one task — approving programs ([p]), configuring script launchers ([l]), approving file access ([f]), approving internet access ([i]), and setting up alerts ([e]). The Dashboard tracks your progress and always shows the next step. Lockdown unlocks only after all prior phases are complete.

A: The HeartSuite kernel is installed alongside your existing kernel via GRUB — it does not replace it. You can boot back to the maintenance kernel at any time from the GRUB menu, and the Dashboard remains accessible on both. The HeartSuite kernel is based on mainline LTS Linux (5.19 or 6.18), not a fork.

Setup Mode reveals compatibility issues before Lockdown enforces anything. During Setup Mode the system logs all activity without blocking — programs that would fail in Lockdown appear in the Dashboard review queues during the observation period. You see what is affected before anything is blocked.

All feature removals are intentional design decisions and documented in System Requirements → Software Compatibility Notes. Software not listed in that table will run without modification. The removed features — eBPF, FUSE, overlay filesystems, unprivileged user namespaces — are the privilege-escalation primitives that give attackers the attack surface, path to root, and bypass of enforcement; most production server workloads do not depend on them. The HeartSuite kernel is built without them by design.

A: No. In Lockdown, a program can only access files and directories that have been explicitly approved through the Dashboard’s File Access review queue. After allowlisting a program’s execution in Phase 2, you approve its file access in Phase 4 — the Dashboard shows every file the program attempted to read or write.

A: The Root Lock by HeartSuite kernel must be loaded during the installation process. Each setup step — run via the System Setup — captures startup and shutdown programs that appeared in the previous boot. Multiple steps are needed because shutdown programs appear on the second boot, and timer-driven processes on later ones. Skipping steps can leave essential programs unapproved, which would cause the system to hang in Lockdown.

A: Check GRUB settings (e.g., uncomment GRUB_DISABLE_LINUX_UUID for VMs), verify installation logs, and try recovery mode.

A: Check the Dashboard’s Suggested Next Step — it will indicate what remains. Press [a] from the System Setup to run the next step. The system reboots automatically after each step that finds new programs.

A: In Lockdown, any program not on the allowlist is blocked. This typically happens after installing new software or a system update that introduces programs Root Lock by HeartSuite has not seen before. To resolve it, select Maintenance ([m]) from the Dashboard — it guides you through switching to Setup Mode, where the new program appears in the review queue. Approve it from there, then re-engage Lockdown.

A: Yes. When the Dashboard’s File Access review queue presents grouped accesses from the same directory, you can approve directory-level access rather than approving each file individually. For example, if Python reads 200 files from /usr/lib/python3/, the review queue groups them and lets you approve access to the entire directory at once.

A: The Dashboard unlocks Lockdown when all prior phases are complete and shows it as the Suggested Next Step. Activation requires typing YES (case-sensitive) to confirm.

A: Root Lock by HeartSuite requires every outbound connection to be explicitly approved per program. When a program attempts a connection during Setup Mode, it appears in the Dashboard’s Internet Access review queue with the destination IP, reverse DNS, and program metadata. Approve the connection from there. In Lockdown, any connection not on the allowlist is refused at the kernel.

A: After the Dashboard shows all review phases complete. Take your time in Setup Mode — allow several days to a week for systemd timers, cron jobs, and infrequent services to appear in the review queues. The status line at the bottom of the Dashboard shows how long Setup Mode has been active (e.g., “Setup Mode — active for 3d 7h”), so you can easily track your observation period. Switching too early will block programs that have not been approved.

A: Lockdown makes all allowlist entries and configuration files immutable (chattr +i), then disables the ability to change immutability flags at the kernel level. No user or program — including root — can modify, delete, or add allowlist entries while Lockdown is active. Use it in production after confirming all programs work correctly in Lockdown.

A: The seal is applied as part of Lockdown activation (see the “How do I activate Lockdown?” entry above). Once confirmed and rebooted, Lockdown + sealed is active automatically on every HeartSuite kernel boot.

A: Select the Maintenance ([m]) from the Dashboard. It detects that Lockdown is active and guides you through a 3-step process: booting the maintenance kernel to remove immutable flags ([u]), making your changes, then rebooting back to the Root Lock by HeartSuite kernel to review new activity and re-engage Lockdown. The Dashboard resumes at the correct step after each reboot.

A: Select the Maintenance ([m]) from the Dashboard. It detects whether Lockdown is active and guides you through the correct path — either a simple switch to Setup Mode, or a guided 3-step process across two reboots if Lockdown requires the maintenance kernel. The Dashboard handles all steps including a pre-maintenance safety checklist.

A: The indicator at the top of the Dashboard immediately shows whether Root Lock by HeartSuite is active and what mode it is in. The Dashboard appears automatically on login.

A: Reboot into the maintenance kernel (select the Maintenance entry from GRUB). The Dashboard resumes automatically on the maintenance kernel and guides you through the maintenance steps. Once back on the Root Lock by HeartSuite kernel, the Dashboard will show any pending items that caused the hang.

A: The Dashboard automatically clears the activity log when all review queues are empty — no manual action is required.