Introduction and overview

• 1: The security problem HJFS solves
• 2: HJFS Overview
• 3: What HJFS Does and Does Not Cover
• 4: Walkthrough: per-version isolation

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.

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.

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.

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).