HeartSuite Joint File System

• 1: Introduction and overview
• 1.1: The security problem HJFS solves
• 1.2: HJFS Overview
• 1.3: What HJFS Does and Does Not Cover
• 1.4: Walkthrough: per-version isolation
• 2: Deployment Scenarios
• 3: Architecture and compatibility
• 4: Advanced Protection
• 5: Real-World Attack Containment
• 6: How HJFS Compares
• 7: Roadmap

1 - Introduction and overview

HeartSuite Joint File System | Prototype

Overview: By default, every program runs with the user’s full file access rights. The OS grants this to any process — including malware and compromised software. HJFS changes that at the filesystem layer. Each program is confined to its own storage area. No other program can read or write its files. This holds even for programs running as root. HJFS works on a standard Linux kernel, so it is available wherever the HeartSuite kernel is not deployed. For execution and network blocking, Root Lock by HeartSuite operates at the kernel level. The two products address different layers and can be used together.

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.
• What HJFS does and does not cover — Where the file isolation boundary holds, where it does not, and what to use alongside it.

1.1 - The security problem HJFS solves

The scribe analogy

Imagine you need to write documents but cannot write yourself, so you hire a scribe. The scribe writes faithfully as you dictate. Then the session ends — and the scribe leaves with your documents. At that point the scribe holds custody of your work. The scribe could demand payment before returning the documents, alter them outside your presence, or copy them for others. This is only possible because you gave the scribe custody over your documents.

A word processor on your computer plays the role of the scribe. When you run any program, the OS grants it your full file access rights. Ransomware exploits exactly this: it opens your files using the same system call as any legitimate program, reads them into memory, encrypts them, and overwrites the originals — all because the OS hands over custody to any program you run, without asking whether you intended it.

To reclaim control, the solution is the same as with the scribe: the user, not the program, holds custody of the documents. HJFS enforces this at the filesystem level.

The root cause

The root cause of most malware damage is a design assumption made in the earliest operating systems and carried forward unchanged: file access permissions are granted to users, not to programs. When a user runs a program, that program inherits the user’s full file access rights. A word processor and a ransomware process running as the same user have identical access to every file that user owns.

This single assumption creates three persistent vulnerabilities that layered security tools cannot fully close.

Three expressions of the problem

1. Unrestricted file access

The OS function open() allows any running program to read, write, or delete any file the current user owns. Malware uses this to encrypt files for ransom, exfiltrate data, or silently corrupt application state. Backup tools can only restore from a previous snapshot taken before the damage; detection tools identify known attack patterns but react after access has already been granted, and miss any attack without a prior signature.

2. Unrestricted network communication

The OS function connect() allows any running program to open outbound network connections. Malware uses this to exfiltrate data and communicate with command-and-control infrastructure. Network filtering blocks known patterns but cannot distinguish malicious traffic from a trusted-looking process already running inside the perimeter.

3. Unrestricted program spawning

The OS function exec() allows any running program to launch other programs. Malware uses this to persist on the system, gain higher access rights, and reach other programs and systems. Policy tools attempt to govern this behavior from outside the OS, but the underlying capability is available to every process by default.

Why layered defenses do not solve this

Each additional security layer treats a symptom without removing the cause. Detection and prevention tools observe the behavior that results from unrestricted OS access and react — after access has already been granted, and only to attacks they already recognize.

HJFS addresses this differently

HJFS replaces user-based file permissions with program-based file permissions, enforced inside the filesystem at the open() call. Each program is confined to its own storage area. Under HJFS, no program can read or write files belonging to another — including when that program runs as root. File access is specific to the program, not inherited from the user.

HJFS addresses the file access dimension. Network connection control and program execution control are outside HJFS scope. Root Lock by HeartSuite handles those dimensions but is not currently compatible with HJFS.

1.2 - HJFS Overview

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 the current user can reach — including programs running as root. That is the root cause of most malware damage. HJFS addresses it directly by binding data files to the program that created them. The modified open() call enforces that binding at every file access: no other program can read or write those files, regardless of privilege. Access control is enforced per program and per program version. Execution control and network connection control are outside HJFS scope. See The security problem HJFS solves for the underlying OS design flaw this corrects.

File isolation in practice

HJFS binds data files to the program that created them. A program can only reach files in its own storage area. That boundary holds even for programs running as root. Malware present on the system cannot read, modify, or encrypt files that belong to another program — the open() call blocks 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. The open() modification marks that area read-only for all programs. Only the official HJFS installer has write access. Programs cannot modify or replace their own binaries.

HJFS operates entirely within the filesystem layer. A standard kernel is sufficient — no kernel modification is required.

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.

A program version is uniquely identified by the concatenation of SHA256 cryptographic hashes of the program executable and all its dynamically linked libraries, combined with the last modification date of those files. Two versions are treated as distinct even if only a single library changed. User-facing utilities display each version with a human-readable install-time identifier (for example, 260208_123022P). The cryptographic hash is the identity HJFS uses internally to enforce isolation.

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 through one of two mechanisms:

• 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: Standard copy and paste between programs is a user-mediated transfer. It requires manual user action and cannot be performed by a program without the user’s knowledge.

Programs cannot permanently delete files. The only deletion operation available to a program is moving a file to trash. A separate utility allows users to view trash contents and permanently delete selected files. All deletions are visible and reversible until the user explicitly confirms permanent removal.

Version management

HJFS includes two utilities:

HJFS_version_manager flags:

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.

If the user created data files under the version being rolled back from — for example, a malicious update installed since the last legitimate version — those files exist only in that version’s storage area. The file transfer utility can copy them to the target version’s storage area before or after the rollback, preserving any legitimate work done under the compromised version.

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 dedicated restore utility allows users to view all versions of a file and restore 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 by HeartSuite’s backup mechanism in two ways. Core Secure 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 alone does not close every window of exposure. Consider a patient form of attack: a malicious update that behaves exactly as expected for months before activating. During those months the user continues working. New data files accumulate inside the malicious version’s storage area. By the time the attack activates — encrypting files for ransom — the user has legitimate data that exists only in that version’s area. Rolling back the program version does not help, because the affected files were created under the malicious version and were never written to the prior version’s area.

This is the attack that automatic data file backup is specifically designed to defeat.

How the backup defeats it

HJFS backs up every write to every data file continuously. Ransomware targets backup systems first because intact backups eliminate the leverage of encryption. HJFS removes that option. The backup area is unreachable to any running program — not through a permission rule that can be changed, but through the same open() enforcement that governs all other isolation boundaries.

When the attack activates, the user can:

1. Stop the malicious program.
2. Use the restore utility to recover 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. The window of loss is limited to files written during the active attack phase — a narrow interval compared to the months the sleeper was dormant.

Security guarantees

HJFS trusts each program only with the storage area that program version created. It does not trust privilege level: root access 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 by HeartSuite: what each covers

Root Lock by HeartSuite and HJFS are not currently compatible and cannot be deployed together. The table below describes what each product covers for reference.

Each product covers dimensions the other does not, but they cannot currently be deployed together. Program execution control and network access control remain outside HJFS scope; organizations requiring those controls should use a dedicated allowlisting tool alongside HJFS.

Status

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

1.3 - What HJFS Does and Does Not Cover

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

Overview: HJFS enforces one thing: file read/write access is per program and per version — including programs running as root. No program can read or write files belonging to another. An attacker who stays within a compromised program’s own storage area is constrained but not stopped. This page states exactly where the boundary is, and what handles 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 enforces. Files belonging to other programs are not reachable — not by name, not by path enumeration, not by any program on the system. The blast radius is structurally bounded to the compromised program’s own 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 HJFS does not cover. If the attacker reads sensitive data from the program’s own files and exfiltrates it over the network, the outbound connection is outside HJFS’s scope. Once data is in memory, the network path is open. Root Lock by HeartSuite closes this gap. 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 enforces. The program can only reach files within its own storage area. Credentials, documents, and configuration files belonging to other programs are inaccessible. The data available for exfiltration is bounded by isolation.

What HJFS does not cover. HJFS controls what data a program can reach; it does not control which connections a program can open. A program that holds data in its own storage area and has an open network path can exfiltrate that data. Root Lock by HeartSuite provides kernel-level gating of outbound connections, with per-program control over which destinations a program can reach. Used alongside HJFS, it closes this gap. See Root Lock by HeartSuite.

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 enforces. HJFS controls what running programs can access. Execution control is Root Lock by HeartSuite’s domain. This is a deliberate division of layers, not a gap.

What HJFS does not cover. A binary placed on the system can be launched. Root Lock by HeartSuite requires any new binary to have an allowlist entry before it can execute. HJFS operates at the filesystem layer; Root Lock by HeartSuite operates at the kernel. See Root Lock by HeartSuite.

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. A malicious update to that program — or an attacker who has compromised it — reads those files.

What HJFS enforces. No other program can reach those files. The isolation is between programs, not between a program and its own data.

What HJFS does not cover. A malicious version of a program has the same access to that program’s storage area as the legitimate version. Secrets stored in a program’s own files are accessible to any version of that program, including a compromised one.

Advanced Protection partially closes this gap for user-facing files. Under the advanced tier, user files can only be opened through an OS-mediated dialog, limiting silent reads even within the program. Internal files remain accessible to the program by name. See Advanced Protection.

Physical access

Physical access is the only path that defeats HJFS file isolation. All software-based attempts to cross program storage boundaries are prevented at the filesystem layer. The specific defeat path is physical access combined with deletion of the HJFS drive. Standard facility controls — locked racks, access logging, physical security policies — are the appropriate countermeasure. See Security guarantees for details.

Complementary tools

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

For the full picture of how Root Lock by HeartSuite and HJFS work together, see HJFS and Root Lock by HeartSuite: what each covers.

1.4 - Walkthrough: per-version isolation

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

This walkthrough uses a small demonstration program, TinyDemo, to show how HJFS keeps data files tied to the specific program version that created them. The same flow is shown in the demo video.

1. Check the installed program version

$ ./start_TinyDemo -V
TinyDemo v1.0

2. Write and read a data file

The w flag writes text to a file; r reads it back.

$ ./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:

./HJFS_version_manager TinyDemo -l

4. Read the existing file from the new version

FileA is still readable — its contents are unchanged:

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

5. Overwrite under the new version

$ ./start_TinyDemo w FileA
$ ./start_TinyDemo r FileA
The pear was a dull green color.
$ ./start_TinyDemo -V
TinyDemo v2.0

Both versions of FileA now exist — version 2 did not destroy or alter the original. Each version owns its own copy in its own storage area.

6. Roll back to the prior version

Confirm the current active version, then set it back to the first:

$ ./HJFS_version_manager TinyDemo -c
$ ./HJFS_version_manager TinyDemo -s 260208_123022P
$ ./start_TinyDemo r FileA
The apple was a shiny red color.

The original data is restored — no backup retrieval, no restore process. The user can switch between versions at will; per-version storage keeps data intact across every installed version, including versions that turn out to be malicious updates.

What this demonstrates

• Per-version storage areas (see HJFS Overview).
• Non-destructive rollback (see Version rollback).
• The HJFS_update_program and HJFS_version_manager utilities (see Version management).

2 - Deployment Scenarios

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

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, giving the user direct control over which files each program can access.

Desktop deployments use the full HJFS model: per-program isolation, per-version storage, and OS-mediated user file 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 is one of the most significant risks in this environment because it operates with the same trust as the legitimate version.

HJFS version isolation addresses this directly. 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 by HeartSuite address complementary layers. Core Secure 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. Together they cover all three OS-level controls — file access, network communication, and program execution.

For production server and regulated deployments, running both closes all three dimensions. See What HJFS Does and Does Not Cover for the specific gaps each fills.

Where HJFS does not apply

Remote or cloud-only storage

HJFS isolates files at the local filesystem layer. Data stored on remote or cloud-hosted filesystems is not protected by HJFS unless HJFS is running on the host where that data resides. A client program accessing remote storage over a network connection is outside HJFS’s scope on the remote side. Network-level connection control for those programs is handled by Root Lock by HeartSuite.

Environments needing execution or network control without HS1

HJFS v1.0 does not control which programs can execute or which network connections programs can open. Where these controls are the primary requirement, use Root Lock by HeartSuite, which enforces both at the kernel level. HJFS can be added alongside it for filesystem-layer isolation.

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. That cooperation is the blocking constraint, not a technical limitation of HJFS itself. Linux is the current deployment target. Support for Windows and macOS is planned.

3 - Architecture and compatibility

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

Dependencies

HJFS requires an existing host file system and cannot operate standalone. A compliant system must use a standard kernel that routes all application file access through the improved file system. The current prototype implements the core file organization without modifying the host file system’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 — the current prototype implements the core file organization concepts without any modifications to the host file system’s code.
• 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.

Long-term vision

The long-term goal is for every file system to be HJFS compliant. HJFS can in principle be deployed anywhere the encompassing file system can be deployed — for example, if integrated into FAT32, it would apply to FAT32 volumes.

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 makes programs installed on that drive safe. Programs on the rest of the computer, running on NTFS, are not protected unless NTFS itself is made HJFS compliant.

Application compatibility

HJFS basic protection requires only OS-level changes — not application changes. 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, but the scope of such changes is expected to be minimal and inconsequential for most deployments.

See Advanced Protection for the tier 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. It is not currently compatible with HJFS and cannot be deployed alongside it. HJFS 1.0 does not include its own network access control; that is planned for a subsequent version.

When implemented in HJFS, each new outbound connection will require explicit user approval rather than relying on static configuration. The approval model differs by deployment type:

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

When network access control is available, the user approves each new connection through an OS dialog:

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. Remote or cloud storage alone does not protect the client program. HJFS applies file isolation at the filesystem layer on the local host. A program running on a machine without HJFS is not subject to HJFS file isolation, regardless of where its data is stored.

4 - Advanced Protection

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

Under basic protection, malware is confined to its own program’s storage area but can still silently access the user’s own documents. Advanced protection closes this gap: it subdivides each program’s storage area into internal files and user files, and requires OS mediation before any user file can be opened. HJFS provides two levels of protection:

Basic protection is the foundation — it runs existing software unchanged. Advanced protection builds on top of it and delivers stronger guarantees for user-facing data files, at the cost of requiring applications to 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 data the user interacts with directly: documents, spreadsheets, images. A program cannot open a user file by specifying its name. Instead, the program invokes a system function that presents a standard OS file-selection dialog. The user makes 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.

This means malware cannot open user files without the user’s knowledge. It must wait for the user to open a file through the dialog. Even then, the user can restrict the opened file to read-only access for the program — the equivalent of handing the scribe a document without the pen.

When the user opens a user file, a file-selection dialog appears. The user picks 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 the user 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.

Why this matters

The combination of both protection levels means:

• No program can access files belonging to another program.
• No program can access the user’s own files without an OS-mediated dialog in which the user makes the selection.

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 to prevent one user’s program session from modifying data visible to another without the other user’s knowledge.

Relationship to basic protection

Advanced protection does not replace basic protection — it adds to it. Version isolation, per-program storage, secure file transfer, automatic data file backup, and all other basic protection features remain active. Advanced protection adds the internal/user file distinction on top.

5 - Real-World Attack Containment

Prototype: The protections described on this page reflect HJFS design intent. HJFS is under active development.

HJFS gives every program its own isolated storage area. No program can read or write files belonging to another. The examples below show what that means for real attacks: damage that would normally cascade across a system stops at the boundary of the program that was compromised.

Where an attack also involves network exfiltration or unauthorized program spawning — beyond HJFS v1.0’s file access scope — those dimensions are addressed by Root Lock by HeartSuite when deployed alongside HJFS.

WannaCry ransomware (CVE-2017-0144)

Attack: 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, with damages estimated at $4 billion including healthcare disruptions and lost productivity.

HJFS containment: WannaCry is confined to its own storage area. It cannot read or write files belonging to other programs, so encryption stops at that boundary. Files created by legitimate programs stay intact and out of reach throughout the attack.

Log4Shell (CVE-2021-44228)

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

HJFS containment: Injected code runs inside the confined storage area of the exploited process. No other program’s files are reachable from there. HJFS version isolation also lets the vulnerable library be identified, rolled back, or replaced without touching data from other versions.

SolarWinds supply chain attack

Attack: 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, with losses estimated in the hundreds of billions across government and intellectual property.

HJFS containment: HJFS identifies program versions by cryptographic hash, so the tainted update gets its own isolated storage area — entirely separate from the legitimate version’s data. The company can roll back to a prior verified version with a single utility command. Data written under the legitimate version stays in that version’s storage area and is unreachable by the tainted build.

Colonial Pipeline ransomware

Attack: 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. The company paid a $4.4 million ransom, with total economic losses exceeding $90 million.

HJFS containment: Ransomware is confined to its own storage area. It cannot reach or encrypt files belonging to other programs. Operational files stay readable throughout the attack. Recovery does not require paying a ransom or restoring from backup — the files were never accessible to the ransomware.

MOVEit Transfer (CVE-2023-34362)

Attack: 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.

HJFS containment: The exploited process is confined to its own storage area. Files belonging to other programs are not reachable — bulk data theft requires access that HJFS does not grant. A secondary encryptor spawned to act on other programs’ files hits the same wall: no program can access files it does not own.

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

Attack: 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, narrowly preventing deployment at scale.

HJFS containment: The backdoored library version carries a different cryptographic hash than the prior legitimate release, so HJFS installs it into its own separate storage area. Data files created under the legitimate version stay in the legitimate version’s storage area — the backdoored version cannot reach them. When the backdoor is discovered, the affected company rolls back to the prior verified version with a single utility command, with no data loss. This is precisely the malicious sleeper attack pattern HJFS automatic data file backup is designed to defeat: even if the backdoored version had been dormant for months before activation, every data file written during that period remains recoverable from the protected backup area — which no program, including the backdoored version, can access or destroy.

Where the attack involves network-level exfiltration or unauthorized program execution, those dimensions are addressed by Root Lock by HeartSuite when deployed alongside HJFS.

Change Healthcare ransomware (2024)

Attack: 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 — the largest healthcare data breach in US history. The company paid a reported $22 million ransom.

HJFS containment: Ransomware is confined to its own storage area. Patient records, billing files, and payment data belonging to other programs sit in structurally separate storage areas that the ransomware cannot enumerate or encrypt. The attack cannot cascade across healthcare systems. Billing and payment infrastructure owned by other programs stays intact throughout the attack. Recovery does not require paying a ransom — the files were never accessible to the ransomware.

6 - How HJFS Compares

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 the user owns, execute any binary it can reach, and open any network connection — and so can any malware running under that user. HJFS addresses one of these three OS-level controls: file read and write access is restricted per program and per version, including when the program runs as root. The question HJFS answers is not “can this user access this file?” but “did this specific program version create it?” Execution control and network connection control are outside HJFS’s scope. Root Lock by HeartSuite handles those dimensions but is not currently compatible with HJFS. This page describes what HJFS controls, what it leaves open, how it can be defeated, and how to think about complementary controls.

Root Lock by HeartSuite and HJFS: two approaches

Three OS-level controls are unrestricted by default on Linux: file access, network communication, and program execution. Every program can open any user file, connect to any network destination, and launch any binary it can reach — and so can any malware running under the same user.

Root Lock by HeartSuite and HJFS share the same goal: closing all three of those controls. They do it in different ways.

Root Lock by HeartSuite 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 by HeartSuite 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 by HeartSuite.

The two products are not currently compatible and cannot be deployed together.

What HJFS is not

HJFS is not network security. HJFS does not control which network connections a program can open. A confined program can still reach any network destination. Isolation limits what data is reachable — a confined program can only read its own files — but the outbound connection itself is not blocked by HJFS. See Network exfiltration.

HJFS is not program execution control. HJFS does not gate which programs can run. A binary placed on the system can be executed. HJFS confines what running programs can access; it does not decide which programs are permitted to run in the first place. See Unauthorized program execution.

HJFS is not filesystem encryption. Files within a program’s storage area are readable by that program in plaintext. Isolation controls which programs can reach a file — it does not protect the file’s contents from a program that legitimately owns it. Use standard disk or volume encryption alongside HJFS for encryption at rest.

HJFS is not a traditional permissions system. 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.

HJFS is not a general-purpose backup system. 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. It is not a substitute for off-site backup, disaster recovery, or compliance-driven backup management.

HJFS is not a detection system. HJFS does not alert on suspicious behaviour. 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 and Root Lock by HeartSuite address complementary OS-level controls. HJFS covers file read and write access at the filesystem layer, with per-program and per-version isolation. Core Secure covers network communication and program execution at the kernel layer. The two products are not currently compatible and cannot be deployed together.

HJFS alone vs. HJFS with Root Lock by HeartSuite

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, which makes it the right choice for cloud instances where the kernel is provider-managed, systems under kernel certification requirements, or organisations with strict change-control policies. Network and execution control are left to other means — network-layer egress filtering, separate allowlisting tools, or existing controls already in place.

Root Lock by HeartSuite covers network connection and program execution control at the kernel level. It is not currently compatible with HJFS and cannot be deployed alongside it. Organisations that need file isolation together with execution and network control should use HJFS with a compatible dedicated allowlisting tool for network and execution coverage.

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: an attacker with physical access to the machine can delete the HJFS drive, removing the isolation layer entirely. Standard physical access controls apply. See Security guarantees.

7 - Roadmap

Prototype: HJFS is under active development.

Current capabilities

HJFS currently includes the following 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