HeartSuite Joint File System

• 1: The OS still treats every program as you
• 1.1: Your word processor inherits every file you own
• 1.2: Each program gets its own storage area
• 1.3: Where the file isolation boundary holds
• 1.4: Walkthrough: per-version isolation
• 2: Where per-program file isolation fits
• 3: HJFS on a stock kernel
• 4: The OS holds the file dialog, not the program
• 5: When ransomware cannot reach another program's files
• 6: What HJFS isolates — and what it complements
• 7: What the HJFS prototype covers today

1 - The OS still treats every program as you

HeartSuite Joint File System | Prototype

Overview: By default, every program you run gets full access to your files, including malware. HeartSuite Joint File System (HJFS) gives each program its own storage area, including programs running as root.

HJFS works on a standard Linux kernel. 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. HJFS also runs on a standard unmodified kernel.

In this section

• The security problem HJFS solves — Why default OS file permissions enable malware damage and how HJFS closes that gap.
• HJFS overview — Core mechanisms, per-version storage, secure file transfer, version management, and patents.
• Walkthrough — A short CLI example showing per-version isolation and rollback in action.
• Protection limits — Where the file isolation boundary holds, and what to use alongside it.

1.1 - Your word processor inherits every file you own

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

Overview: When you run a program, the OS grants it every file you can reach. A word processor and ransomware running as the same user have the same access.

HeartSuite Joint File System (HJFS) stops a program from inheriting everything you can reach: each program gets only its own files, isolated per program and per version, including programs running as root.

The root cause

Operating systems grant file permissions to users, not to programs, and that is still the default. As a result, a word processor and a ransomware process running as the same user have identical access to every file that user owns.

Ransomware opens your files using the same system call as any legitimate program, reads them, encrypts them, and overwrites the originals. Backup can only restore a snapshot taken before the damage, and detection reacts after access was already granted, and only to attacks it already recognizes.

What HJFS changes

HJFS replaces user-based file permissions with program-based file permissions, enforced inside the filesystem. Each program has its own storage area. No other program can read or write those files, including programs running as root.

Which programs run and which network connections they open stay with Root Lock by HeartSuite. On a Root Lock kernel, HJFS and Root Lock can share the host. See Protection limits.

1.2 - Each program gets its own storage area

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

Overview: On a standard Linux system, any program can open any file you can reach, including programs running as root. HeartSuite Joint File System (HJFS) binds data files to the program version that created them, so no other program can read or write those files, regardless of privilege. Which programs run and which network connections they open stay with Root Lock by HeartSuite. See The security problem HJFS solves.

File isolation in practice

A program can reach only the files in its own storage area, and that boundary holds even for programs running as root. Malware already present on the system therefore cannot read, modify, or encrypt files that belong to another program: the filesystem’s open() call refuses the attempt before it reaches the data.

Technical implementation

HJFS moves file access enforcement out of the kernel’s user-permission model and into the filesystem itself. It consists of three parts:

• Additional code integrated into the filesystem’s open() call — the function the OS invokes whenever a program opens a file. Access policy is enforced at that point.
• Tools for installing and updating programs into the HJFS structure.
• A version selector that determines which program version is active when a program starts.

Executables are stored in a separate area, which the open() modification makes read-only for every program except the official HJFS installer. Programs therefore cannot modify or replace their own binaries.

Because HJFS operates entirely within the filesystem layer, a standard kernel is sufficient.

When a program opens a file, the modified open() call routes the request to that program’s isolated storage area:

The restructured filesystem separates system files, executables, and per-program data into distinct top-level areas:

Per-version storage

HJFS enforces isolation at the version level, not just the program level. Each installed version of a program receives its own dedicated storage area.

HJFS trusts a program only with the storage area that version created. Storage areas belonging to other programs — or to other versions of the same program — are outside that trust boundary, even when the program runs as root.

HJFS identifies a version by a hash of the executable and its libraries, so a change to a single library makes a new version. Utilities show a human-readable install-time identifier (for example, 260208_123022P), but the hash is what HJFS enforces.

When a program opens a versioned file, the open() call resolves both the program name and the version hash before locating the file:

This means:

• When a program is updated, the new version gets its own storage area. The previous version’s binary, libraries, and data files remain intact.
• A malicious update cannot reach or destroy files created by earlier versions.
• Users can roll back to any previous version and read the original files exactly as they were.

Secure file transfer between programs

Because each program is confined to its own storage area, moving data between programs requires explicit user action:

• Copy utility: Copies a file from one program’s storage area directly to another’s. Every transfer is an explicit, auditable operation.
• Transfer area: A neutral staging location where a file can be deposited once and made available for other programs to read and copy to their own areas. Programs can read from the transfer area but cannot write to other programs’ areas directly.
• Clipboard: Copy and paste between programs requires your action, so a program cannot move data through the clipboard on its own.

Programs can only move a file to trash, never delete it permanently. A separate utility shows trash contents and permanently deletes selected files after you confirm.

Version management

HJFS_update_program installs a new version. HJFS_version_manager lists installed versions, shows the active one, and sets it. The Walkthrough runs those commands.

Version rollback

Because each version has its own storage area, rolling back is non-destructive. Setting the active version to a prior release makes the original files immediately accessible — no restore process, no backup retrieval. Prior executables, libraries, and data files remain untouched in their own subareas.

Data files created under the version you roll back from exist only in that version’s storage area. The file transfer utility can copy them to the target version before or after rollback.

The example below shows a program called SimpleEdit after an update on November 12. The May 6 version is preserved in its own subarea; the installer stores the prior executables before overwriting the current ones:

Automatic data file backup

HJFS automatically backs up every version of every data file to a protected storage area. No program can reach that area — including programs running as root. A restore utility shows every version of a file and restores any of them.

This is distinct from program version rollback. Program version rollback restores a prior executable and its libraries. Data file backup maintains version history of the data files themselves, independent of which program version created them.

HJFS automatic backup differs from Root Lock’s backup mechanism in two ways. Root Lock backs up admin-configured directories on every write — an administrator selects which directories are protected. HJFS backup requires no configuration: every data file written by any program is backed up automatically by the filesystem, covering every program’s storage area from first use.

The malicious sleeper attack

Program version isolation leaves a window, because a malicious update can behave as expected for months before it activates. During that time, new data files accumulate inside the malicious version’s storage area, and rolling back the program version leaves them where they were written: they were never in the prior version’s area.

How the backup defeats it

HJFS copies every write to a protected area no program can open, including programs running as root. Ransomware targets backups first because intact backups remove the leverage of encryption, and HJFS removes that option at the same open() boundary that isolates program storage.

When the attack activates:

1. Stop the malicious program.
2. Restore every data file to the version that existed before the attack.
3. Copy those restored files to the prior legitimate program version’s storage area.
4. Roll back the program version to the legitimate one.

Every file created before the attack is recoverable. Loss is limited to files written during the active attack, not the months the sleeper was dormant. See Attack examples for the XZ pattern.

Security guarantees

HJFS trusts each program only with the storage area that program version created. Root access stays inside the same storage area: privilege level does not expand what a program can open.

The trust boundary is enforced at the filesystem layer, below all running software. The only path around it is physical: removing the HJFS drive bypasses the enforcement entirely.

Patents

HJFS is based on innovations patented by HeartSuite:

HJFS and Root Lock: what each covers

On a Root Lock kernel, HJFS and Root Lock can share the host. HJFS also runs on a standard unmodified kernel.

See How HJFS compares for when to run HJFS alone and when to run it beside Root Lock.

Status

HJFS is a prototype. Capabilities, configuration, and deployment details are subject to change.

1.3 - Where the file isolation boundary holds

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

Overview: HeartSuite Joint File System (HJFS) keeps every program inside its own storage area, including programs running as root, so no program can read or write files belonging to another. A compromised program can still damage the files it already owns.

This page describes where the boundary holds, what a compromised program can still do inside it, and which tools cover the rest.

An attacker uses a compromised program within its own storage area

The scenario. An attacker gains control of a running program — through a vulnerability, a malicious update, or a backdoor compiled into an approved binary. The program is already running and has legitimate access to its own storage area.

What HJFS does. The compromised program cannot reach files belonging to other programs, either by name or by path enumeration, so the damage stops at its own storage area.

Within that area, every write is automatically backed up to a protected location no program can access. Recovery is always available: the restore utility returns any file to any prior version, including versions created before the compromise.

What it does not cover. HJFS does not control network connections, so the attacker can read sensitive data from the program’s own files and send it out over the network. Root Lock by HeartSuite covers that connection; see Network exfiltration below.

Network exfiltration

The scenario. A compromised program reads data from its own storage area, then opens an outbound connection to an attacker-controlled server.

What HJFS does. The program can reach only the files in its own storage area, so credentials, documents, and configuration files belonging to other programs are out of its reach. What the attacker can send out is limited to that program’s own files.

What it does not cover. HJFS does not decide which destinations a program may connect to, so it does not stop the upload itself. Root Lock gates outbound destinations per program. See Root Lock.

Unauthorized program execution

The scenario. An attacker downloads a tool — a privilege escalation script, a credential dumper, a reverse shell — and attempts to run it.

What HJFS does. HJFS confines what a running program can open, so a newly started tool cannot reach files belonging to other programs.

What it does not cover. HJFS does not decide which programs may execute, so it does not stop the downloaded tool from starting. Under Lockdown, Root Lock requires any new binary to have an allowlist entry before it can execute. See Root Lock.

Sensitive data within a program’s own storage area

The scenario. A program stores credentials, API keys, or other secrets in its own data files. An attacker who has compromised the running version of that program reads those files.

What HJFS does. No other program can reach those files. A malicious update is a new version with its own empty storage area, so it reaches those secrets only if you copy them into its area with the file transfer utility. See Walkthrough.

What it does not cover. The isolation is between programs and between versions, not between a running version and its own data, so a compromised version can read the secrets stored in its own files. Advanced protection narrows this for user-facing files, which the program can open only through an OS-mediated dialog, so it cannot read them silently. Internal files remain accessible to the program by name. See Advanced protection.

Physical access

Physical access to the drive is the path that defeats HJFS file isolation: removing the HJFS drive and reading it elsewhere bypasses it. While the drive is present, the filesystem layer refuses every software attempt to cross program storage boundaries.

Standard facility controls — locked racks, access logging, console IAM, physical security policies — are the appropriate countermeasure for the drive itself. See Security guarantees.

Complementary tools

HJFS provides filesystem-level file isolation. Network monitoring, detection, and execution control address different layers and work alongside it.

On a Root Lock kernel, HJFS and Root Lock can share the host. See HJFS and Root Lock: what each covers.

1.4 - Walkthrough: per-version isolation

Prototype: Commands and output shown reflect the current prototype and may change.

Overview: Each installed version of a program has its own storage area. After an update, the new version cannot open files the old version created. Rolling back makes the old files available again — they were never copied into the new area.

HJFS overview explains why versions are isolated; this walkthrough shows the same rule from the command line.

1. Check the installed program version

$ ./start_TinyDemo -V
TinyDemo v1.0

2. Write and read a data file under v1

The w flag writes text to a file; r reads it back. Both calls run as TinyDemo v1, so they share v1’s storage area.

$ ./start_TinyDemo w FileA
$ ./start_TinyDemo r FileA
The apple was a shiny red color.

3. Build and install a new version

$ ./make_TinyDemo-2.sh
$ ./HJFS_update_program TinyDemo TinyDemo TinyDemo.hash

List installed versions. The identifiers are install-time labels; HJFS enforces the hash.

$ ./HJFS_version_manager TinyDemo -l
260208_123022P  TinyDemo v1.0  (hash …)
260208_124510P  TinyDemo v2.0  (hash …)  [active]

4. v2 cannot read v1’s FileA

v2 is now active. FileA still exists in v1’s storage area, but v2 has its own area, and FileA is not in it.

$ ./start_TinyDemo -V
TinyDemo v2.0
$ ./start_TinyDemo r FileA
FileA: not in this version's storage area

This failed read is the isolation at work. A malicious update is also a new hash, so it too starts with an empty area and cannot open the prior version’s files. To give v2 a copy of FileA, use the file transfer utility; v2 cannot open v1’s copy itself. See Secure file transfer.

5. Write FileA under v2

v2 can create its own FileA. That is a different file in a different area. v1’s copy is unchanged.

$ ./start_TinyDemo w FileA
$ ./start_TinyDemo r FileA
The pear was a dull green color.

6. Roll back to v1

Confirm the active version, then set it back to the first. Rollback copies and merges nothing; it makes v1’s area the one open() resolves.

$ ./HJFS_version_manager TinyDemo -c
260208_124510P  TinyDemo v2.0  [active]
$ ./HJFS_version_manager TinyDemo -s 260208_123022P
$ ./start_TinyDemo -V
TinyDemo v1.0
$ ./start_TinyDemo r FileA
The apple was a shiny red color.

v2’s pear file is still in v2’s area; it is only hidden while v1 is active. The file transfer utility can copy it across if you need it. See Version rollback.

2 - Where per-program file isolation fits

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

Overview: HeartSuite Joint File System (HJFS) isolates files per program on a stock kernel, including as root. Which programs run and which network connections they open stay Root Lock’s domain.

On a Root Lock kernel, both can share the host. HJFS also runs on a standard unmodified kernel.

Where HJFS fits

Desktop and workstation environments

The HJFS isolation model maps directly onto what desktop programs need: each program confined to its own storage area, with no path between them. A word processor cannot touch a browser’s files, and neither can reach files belonging to any other program.

With Advanced protection, user-facing documents are opened only through an OS-mediated dialog, so you choose which files each program can access.

Multi-user systems

On systems with multiple user accounts, HJFS layers per-user isolation on top of per-program and per-version isolation. A program running under one user account cannot access files created by the same program under a different account. This separation is structural, not policy-based — the storage areas are physically distinct.

Software supply chain environments

Development, build, and CI systems are high-value targets for supply chain attacks. A tainted dependency or build tool update operates with the same trust as the legitimate version.

HJFS version isolation addresses this. When a program is updated, its prior version — including all its libraries and data files — is preserved in a separate storage area. A tainted update cannot access or destroy data created by the legitimate version. Rollback to the prior clean version is a single utility command, with no data loss.

Regulated environments

Healthcare, financial, legal, and government systems often require demonstrable data segregation — evidence that one program’s data cannot be accessed by another. HJFS provides this at the filesystem architecture level. The filesystem enforces program boundaries: no policy rule can be misconfigured to grant one program another’s files.

Standard-kernel environments

HJFS runs on a standard kernel — no kernel modification required. This makes it deployable where a modified or custom kernel is not permitted: cloud instances on AWS, Google Cloud, Azure, DigitalOcean, or Linode, systems subject to kernel certification requirements, and organisations with strict change-control policies around the kernel.

Alongside Root Lock by HeartSuite

HJFS and Root Lock address complementary layers. Root Lock controls program execution and network access at the kernel level. HJFS controls file read and write access at the filesystem level and adds per-version data isolation.

On that host they cover all three OS-level controls — file access, network communication, and program execution. See Protection limits.

Where another control owns the workload

Remote or cloud-only storage

HJFS isolates files at the local filesystem layer. Isolation on remote or cloud-hosted filesystems holds only where HJFS is running on the host that stores the data.

A client program accessing remote storage over a network connection is isolated on the local host. On the remote side, isolation holds only where HJFS is running. Network-level connection control for those programs is handled by Root Lock.

Environments needing execution or network control

Which programs can execute and which network connections they can open stay Root Lock’s domain. Where those controls are the primary requirement, use Root Lock, which enforces both at the kernel level.

HJFS can be added alongside it for filesystem-layer isolation. Per-program file isolation on a standard kernel still holds.

Windows and macOS

HJFS on Linux uses standard kernel filesystem registration — no special permissions or OS modifications required.

On Windows and macOS, registering a filesystem requires cooperation from Microsoft or Apple respectively. Linux is the current deployment target because that registration is a standard kernel operation there. Support for Windows and macOS is planned. File isolation on Linux still holds.

3 - HJFS on a stock kernel

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

Overview: HeartSuite Joint File System (HJFS) isolates files inside the host filesystem on a stock kernel, because enforcement sits in the filesystem open() path rather than in a custom kernel.

HJFS sits on an existing host filesystem, and the current prototype implements the core file organization without modifying the host filesystem’s code directly.

Integration and vendor cooperation

HJFS integration involves two steps:

• FS source code integration: A minimal amount of HJFS source code is integrated into the file system’s open() call. The scope of changes is small.
• Kernel registration: The HJFS-modified file system must be registered with the kernel. On Linux, this is a standard operation. On Windows and macOS, it requires cooperation from Microsoft or Apple respectively. Kernel registration is planned for a subsequent release.

OS support

HJFS is designed to work on Linux, Windows, and macOS.

Partial deployment: portable HJFS drive

Adding an HJFS-formatted disk or USB drive to a Windows computer isolates programs installed on that drive. Files on the HJFS volume stay isolated per program. Programs on the rest of the computer stay on NTFS until NTFS itself is made HJFS compliant.

Application compatibility

HJFS basic protection requires only OS-level changes, so existing application software runs unchanged for the vast majority of programs.

Applications hard-coded to access global system paths outside their own storage area (such as /usr or /proc) would need minor adjustments. The scope of such changes is expected to be small.

See Advanced protection for the level that does require application modifications, and what it adds in return.

Container compatibility

Containers running on an HJFS-compliant host filesystem benefit from the same per-program file isolation as native processes. Each containerized program is confined to its own storage area. Container orchestration and scheduling are unaffected.

Network access control

Root Lock by HeartSuite provides network access control today with kernel-level gating of outbound connections, and on a Root Lock kernel HJFS and Root Lock can share the host.

HJFS network mediation is planned; until it ships, file isolation on a standard kernel works without it. See Roadmap.

When that HJFS path ships, each new outbound connection requires explicit approval rather than a static list:

• Desktop: you approve each new connection through an OS confirmation dialog.
• Server: access is governed by pre-approved utilities or admin-defined policies, without per-action prompts.

Planned desktop path:

Blocking simulated user input

HJFS-compliant OS distributions disable the ability for a program to simulate user mouse clicks or keypresses in ordinary user sessions. Without this, a malicious program could simulate a user emptying the trash, approving a file open dialog, or confirming a network connection — faster than a user can observe or stop them.

Local deployment requirement

HJFS must run locally on every machine it protects, because it applies file isolation at the filesystem layer of the local host. A program running on a machine without HJFS stays on that machine’s native filesystem, regardless of where its data is stored, so remote or cloud storage alone does not isolate it.

4 - The OS holds the file dialog, not the program

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

Overview: Under basic protection, malware stays in its own storage area but can still silently open your documents. Advanced protection holds the file dialog in the OS, not in the program.

HJFS provides two levels of protection:

Basic protection runs existing software unchanged. Advanced protection builds on it with stronger guarantees for user-facing data files, but applications must be updated to use the new OS functions.

Internal files and user files

Advanced protection subdivides each program’s per-version storage area into two types.

Internal files are managed directly by the program using file names. They are hidden from user utilities — they cannot be browsed, copied, or accessed outside the program that owns them. A spell-checker dictionary, a configuration file, or game state data are examples of internal files.

User files are the documents, spreadsheets, and images you work with. A program cannot open a user file by specifying its name; instead it invokes a system function that presents a standard OS file-selection dialog, and you make the selection.

The OS opens the file and passes a file handle to the program — not a path. The program never learns the file’s location in the broader filesystem.

Malware therefore cannot open your user files on its own: it has to wait until you open a file through the dialog, and you can restrict that file to read-only for the program.

When you open a user file, a file-selection dialog appears. You pick the file; the OS resolves and opens it, passing only a handle to the program:

Exporting and importing data

Because internal files are hidden and user files require OS mediation, HJFS advanced protection provides two explicit system functions for moving data across the boundary:

Export: A program can write internal file data to a user file, making it available to you or to other programs. To prevent data mixing, no other user file may be open by the program during the export operation.

Import: A program can read from a user file and write the data into its internal files. This is the standard path for a program to accept externally supplied data — a document being opened for editing, for example.

Both functions are explicit, auditable, and user-initiated through the OS dialog.

Multiple users

On a multi-user system, each user’s storage is kept separate first. Within that per-user space, storage is divided by program. Within each program, storage is divided by version. Within each version, storage is split into internal and user subareas.

A program running as user X cannot access files created by user Y, even within the same program version.

Internal files that contain no user-specific data — shared configuration or reference data, for example — can be stored in a user-independent area accessible to all users of the program.

Programs are restricted to read-only access of such common files. That prevents one user’s program session from modifying data visible to another without the other user’s knowledge.

Advanced protection adds the internal/user file distinction on top of basic protection. Version isolation, per-program storage, secure file transfer, and automatic data file backup remain active.

5 - When ransomware cannot reach another program's files

Prototype: The protections described on this page reflect HJFS design intent. HJFS is under active development. Incident facts below are taken from public reporting, not from HeartSuite exploitation tests.

Overview: When a program is compromised, damage usually spreads through every file that user can reach. HeartSuite Joint File System (HJFS) is designed to stop that spread at the compromised program’s storage area. Each incident below also shows what HJFS leaves exposed, so you can see where another control has to take over.

Which programs run and which network connections they open stay with Root Lock by HeartSuite, and on a Root Lock kernel HJFS and Root Lock can share the host. A compromised program can still damage files it already owns — see Protection limits.

WannaCry ransomware (CVE-2017-0144)

What happened. An SMB vulnerability let malware spread across networks and encrypt files on every system it reached. Over 200,000 systems across 150 countries were affected.

What the campaign needed. A new encryptor process that could open files belonging to other programs on the same host, plus a network worm path.

What HJFS does. HJFS confines that encryptor to its own storage area. The encryptor cannot read or write files belonging to other programs, so the encryption stops at that boundary.

What it does not cover. Files in the encryptor’s own area remain exposed to it, and automatic backup is how you recover them. Network spread stays with Root Lock.

Log4Shell (CVE-2021-44228)

What happened. A remote code execution flaw in the Log4j library let attackers inject and run arbitrary code, then use that foothold to reach other systems.

What the campaign needed. Code running inside an already-trusted process, then a path from that process to other programs’ files or to the network.

What HJFS does. HJFS keeps injected code inside the exploited process’s storage area, so no other program’s files are reachable from there. Because each version is isolated, the vulnerable library version can be identified and rolled back without touching data from other versions.

What it does not cover. HJFS does not stop the remote code execution itself, because the code runs inside an already-trusted process. Secrets already in that process’s own files remain readable by it, and outbound callbacks stay with Root Lock.

SolarWinds supply chain attack

What happened. A tainted software update carried a backdoor that gave attackers persistent access for exfiltration and espionage over months. Roughly 18,000 organisations were affected, including multiple US federal agencies.

What the campaign needed. A new binary (or a new version of a trusted binary) that could still open files written by the legitimate version, plus months of quiet access.

What HJFS does. HJFS identifies program versions by cryptographic hash, so the tainted update gets its own isolated storage area, separate from the legitimate version’s data. You can roll back to a prior verified version, and data written under the legitimate version stays in that version’s storage area.

What it does not cover. Data written while the tainted version was active stays in that version’s area, and rolling back does not bring it into the legitimate version. Automatic backup covers that window — see The malicious sleeper. Network exfiltration from the backdoor’s own files stays with Root Lock.

Colonial Pipeline ransomware

What happened. Compromised credentials gave attackers the access they needed to deploy ransomware that encrypted operational data and forced a six-day shutdown of the largest fuel pipeline in the United States.

What the campaign needed. Either a new encryptor binary that could open operational files, or encryption from inside the programs that already owned those files.

What HJFS does. If the encryptor is a separate program, it cannot reach files belonging to other programs.

What it does not cover. If encryption ran inside the operational software that already owned those files, HJFS does not stop it — that is a program hurting files it already owns. Credential theft and lateral movement stay with Root Lock.

MOVEit Transfer (CVE-2023-34362)

What happened. SQL injection in a managed file transfer application enabled mass data theft and encryption. Over 2,000 organisations across government, healthcare, and financial sectors were affected.

What the campaign needed. Code running inside the file-transfer application that already stored the files being stolen.

What HJFS does. A secondary encryptor spawned as a different program cannot open files it does not own.

What it does not cover. If theft runs inside MOVEit itself, HJFS does not hide the application’s files from the application. See Sensitive data within a program’s own storage area.

XZ Utils supply chain attack (CVE-2024-3094)

What happened. A patient attacker spent approximately two years as a trusted contributor to the XZ Utils open-source compression library, gradually building commit access before inserting a backdoor in versions 5.6.0 and 5.6.1.

The backdoor was designed to allow unauthorized SSH authentication on affected systems. It was discovered in March 2024 weeks before reaching stable Linux distributions.

What the campaign needed. A new library hash (a new HJFS version) plus a path from that version to prior data, or to SSH authentication.

What HJFS does. The backdoored library version carries a different cryptographic hash than the prior legitimate release, so HJFS installs it into its own storage area. Data files created under the legitimate version stay there — the backdoored version cannot reach them. You can then roll back to the prior verified version.

This is the malicious sleeper pattern. For files written during the backdoored version’s life, HJFS automatic data-file backup is designed to close the gap: even if that version had been dormant for months, writes from that period remain in the protected backup area, which no program, including the backdoored version, can open.

What it does not cover. HJFS does not control execution or network access, so it does not stop the backdoor’s unauthorized SSH authentication. Those controls stay with Root Lock.

Change Healthcare ransomware (2024)

What happened. The ALPHV/BlackCat ransomware group breached Change Healthcare, a clearinghouse processing a large share of US patient healthcare claims. The February 2024 attack disrupted healthcare billing and payment processing across the United States for weeks.

UnitedHealth Group disclosed that approximately 190 million individuals had data affected.

What the campaign needed. Either a new encryptor that could open billing and patient files, or encryption from inside the programs that already stored them.

What HJFS does. A separate ransomware binary cannot enumerate or encrypt files belonging to other programs.

What it does not cover. If patient records live in the billing stack’s own files, HJFS does not hide them from a compromised billing program. See Protection limits.

6 - 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, so 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, but HJFS still confines what it can access once it runs. See Unauthorized program execution.

Encryption. Files within a program’s storage area are readable by that program in plaintext, because isolation controls which programs can reach a file, not how it is stored. Use standard disk or volume encryption alongside HJFS for encryption at rest.

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.

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.

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.

7 - What the HJFS prototype covers today

Prototype: HJFS is under active development.

Current capabilities

HJFS implements core file organization with the host file system code left unchanged — enabling deployment on standard, unmodified kernels. See Architecture and compatibility for details.

Planned

Next release

Subsequent releases