1 - Your word processor inherits every file you own
Malware encrypts your files with the same open() your editor uses. HJFS keeps custody with you, not with the program you ran.
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) keeps file access with you, not with the program. Isolation is per program and per version, including as root.
The root cause
File permissions are granted to users, not to programs. That assumption is still the default. 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 restores a snapshot taken before the damage. 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, both can share the host. See Protection limits.
2 - Each program gets its own storage area
HJFS confines programs to their own files. The OS default — every program inherits your documents — is the hole this closes.
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.
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
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.
Identity is the executable plus its libraries, hashed. A single library change is a new version. Utilities show a human-readable install-time identifier (for example, 260208_123022P); 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. A program cannot do it without you.
Programs cannot permanently delete files. They can only move a file to trash. 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. A malicious update can behave as expected for months before it activates. New data files accumulate inside that version’s storage area. Rolling back the program version leaves those files 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 backup first because intact backups remove the leverage of encryption. HJFS removes that option at the same open() boundary that isolates program storage.
When the attack activates:
- Stop the malicious program.
- Restore every data file to the version that existed before the attack.
- Copy those restored files to the prior legitimate program version’s storage area.
- 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:
| Patent | Title | Issued |
|---|
| US 11,822,699 B1 | Preventing Surreptitious Access to File Data by Malware | November 21, 2023 |
| US 11,983,288 B1 | Operating System Enhancements to Prevent Surreptitious Access to User Data Files | May 14, 2024 |
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.
| Root Lock | HJFS |
|---|
| Enforcement layer | Kernel | Filesystem (open() call) |
| Kernel requirement | Modified Root Lock kernel | Standard kernel |
| Program execution control | Yes | No |
| Filesystem path control | Yes | Yes |
| Network access control | Yes | Planned |
| Per-program-version file isolation | No | Yes |
| Audited cross-program file transfer | No | Yes |
Which programs run and which network connections they open stay Root Lock’s domain. See How HJFS compares.
Status
HJFS is a prototype. Capabilities, configuration, and deployment details are subject to change.
3 - Where the file isolation boundary holds
Where HJFS file isolation holds, where a program can still hurt you inside its own area, and what to run alongside it.
Prototype: Content on this page reflects current design intent and will be updated as the product matures.
Overview: A compromised program can still hurt the files it already owns. HeartSuite Joint File System (HJFS) still keeps that program inside its own storage area, including as root.
No program can read or write files belonging to another. This page states where that boundary holds, 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 does. Files belonging to other programs are not reachable — not by name, not by path enumeration, not by any program. Damage stops at 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 it does not cover. If the attacker reads sensitive data from the program’s own files and exfiltrates it over the network, this particular gate does not apply to the outbound connection. File isolation still holds: other programs’ files stay unreachable. Root Lock by HeartSuite closes the network 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 does. 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 it does not cover. If a program holds data in its own storage area and has an open network path, this particular gate does not apply to that connection. The reachable set is still that program’s own files. 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. Files belonging to other programs stay unreachable even if a new binary starts.
What it does not cover. If an attacker downloads a new binary and launches it, this particular gate does not apply to execution. Once it is running, HJFS still confines it to its own storage area. 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. A malicious update to that program — or an attacker who has compromised it — reads those files.
What HJFS does. No other program can reach those files. The isolation is between programs, not between a program and its own data.
What it does not cover. If a malicious version of a program reads secrets stored in that program’s own files, this particular gate does not apply inside that area. Files belonging to other programs remain unreachable. Advanced protection further limits silent reads of user-facing files: those open only through an OS-mediated dialog. Internal files remain accessible to the program by name. See Advanced protection.
Physical access
Physical or serial-console access is the 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 removing the HJFS drive. Standard facility controls — locked racks, access logging, console IAM, physical security policies — are the appropriate countermeasure. File isolation still holds for every software path while the drive is present. See Security guarantees.
HJFS provides filesystem-level file isolation. Network monitoring, detection, and execution control address different layers and work alongside it.
| Adjacent domain | Complementary tool |
|---|
| Network exfiltration | Root Lock (kernel-level network allowlisting) or network-layer egress controls |
| Unauthorized program execution | Root Lock (kernel-level program allowlisting) |
| Detection within approved boundaries | SIEM, NDR, endpoint detection tools |
| Secrets management within a program | Secrets management tools; Advanced protection for user files |
On a Root Lock kernel, both can share the host. See HJFS and Root Lock: what each covers.
4 - Walkthrough: per-version isolation
Upgrade a program, keep v1’s data out of v2’s reach, roll back. A short CLI walkthrough of HJFS 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.
See HJFS overview for why. This walkthrough is the CLI shape of that rule.
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. It is not in v2’s.
$ ./start_TinyDemo -V
TinyDemo v2.0
$ ./start_TinyDemo r FileA
FileA: not in this version's storage area
That miss is the isolation. A malicious update is a new hash, so it starts with an empty area and cannot open the prior version’s files. To give v2 a copy, use the file transfer utility — not open() from v2. 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 does not copy or merge files. 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 is still in v2’s area. It is not gone; it is not visible while v1 is active. The file transfer utility can copy it across if you need it. See Version rollback.