What HJFS isolates — and what it complements

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: Every program on a Linux system can, by default, read any file you own, execute any binary it can reach, and open any network connection — and so can any malware running under that user.

HeartSuite Joint File System (HJFS) addresses one of these three OS-level controls: file read and write access is restricted per program and per version, including as root. Which programs run and which network connections they open stay with Root Lock by HeartSuite. On a Root Lock kernel, both can share the host.

Root Lock and HJFS: two approaches

Three OS-level controls are unrestricted by default on Linux: file access, network communication, and program execution.

Root Lock and HJFS share the same goal: closing all three. They do it in different ways.

Root Lock is production-ready today. It works with the existing Linux OS: you configure allowlist entries, tighten them down, and enable Lockdown. With Lockdown enabled, only explicitly permitted programs, files, and network destinations are allowed. Everything else is blocked.

HJFS redesigns the file access layer from the ground up. Every program is confined to its own private storage area at the filesystem level. Prior versions of programs are preserved automatically before any update overwrites them. Cross-program file access is architecturally impossible, not policy-dependent.

Network access mediation and OS-mediated user-file access are planned for subsequent releases.

For production deployments today

Root Lock is production-ready for Linux servers. Tight allowlist configuration, Lockdown enabled, and restricted backup directories provide strong real-world protection with existing software.

HJFS eliminates entire risk classes — cross-program file leakage, malicious updates reaching prior-version data, programs permanently deleting files — by design, without depending on correct admin configuration. It runs on a standard unmodified kernel.

Network access mediation and execution control are planned for subsequent releases. For those controls today, use Root Lock. On a Root Lock kernel, both can share the host.

What HJFS is

HJFS is per-program file isolation on a standard unmodified kernel. Each program has its own storage area, including as root. Which programs run and which network connections they open stay with Root Lock.

Network. Which connections a program can open is Root Lock’s domain. Isolation still limits what data is reachable — a confined program can only read its own files. See Network exfiltration.

Execution. Which programs may start is Root Lock’s domain. A binary placed on the system can be launched. HJFS still confines what running programs can access. See Unauthorized program execution.

Encryption. Files within a program’s storage area are readable by that program in plaintext. Isolation controls which programs can reach a file. Use standard disk or volume encryption alongside HJFS for encryption at rest. Per-program isolation still holds on the plaintext files.

Permissions. Standard OS permissions are user-based: they answer “can this user read this file?” HJFS is program-based: it answers “did this program create this file?” The two operate at different levels and are complementary.

Backup. HJFS automatically backs up every data file each time it is written, to a protected area no program can access. This provides fine-grained version history for ransomware recovery and rollback. Off-site backup, disaster recovery, and compliance-driven backup management stay with dedicated backup infrastructure. The per-write history still holds for files HJFS itself stores.

Detection. For behavioural detection, fleet correlation, and incident response, SIEM and NDR tools remain the right answer and should run alongside HJFS.

What HJFS complements

HJFS covers file read and write access at the filesystem layer, per program and per version. Root Lock covers network communication and program execution at the kernel layer.

HJFS alone, and on a Root Lock kernel

HJFS alone fits deployments where the primary risk is lateral file access across programs, data destruction by ransomware, or supply chain updates that taint data created by prior versions. It runs on a standard kernel — cloud instances with a provider-managed kernel, systems under kernel certification, or organisations that keep a stock kernel.

Network and execution control on that host stay with existing tooling: egress filtering, separate allowlisting, or whatever is already in place.

On a Root Lock kernel both can share the host: Root Lock for execute and network, HJFS for per-program file isolation and versioning. Per-program file isolation on a standard kernel still holds when you run HJFS alone.

Positioning relative to common security categories

How HJFS can be circumvented. HJFS file isolation operates at the filesystem layer, below any running software. No program — regardless of privilege — can cross program storage boundaries while HJFS is present.

The one path around it is physical or serial-console access: an attacker who can remove the HJFS drive removes the isolation layer. Standard physical and console controls apply. See Security guarantees. File isolation still holds for every software path while the drive is present.