The security problem HJFS solves
The OS design flaw that makes malware damage possible, and how HJFS addresses it.
Introduction and overview
Overview of HeartSuite Joint File System, its design goals, and how it differs from kernel-based security.
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.
HJFS Overview
How HJFS confines programs to their own storage areas — eliminating the OS’s default of shared file access across all programs.
What HJFS Does and Does Not Cover
Where HJFS’s file isolation holds, where it does not, and what to use alongside it.
Walkthrough: per-version isolation
A short CLI walkthrough showing how HJFS preserves data across program versions, including rollback.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.