Capability-Dropping Filesystem-Immutable-Bit Two-Actor Write Protocol

Executive Summary

This claim discloses a designed two-actor write protocol for a WORM storage daemon in which the process serving normal network-facing read/write traffic is architected to permanently drop the Linux CAP_LINUX_IMMUTABLE capability from its own process at startup, while a second, separate, minimally-privileged sidecar process retains that capability and is the only actor that ever sets the filesystem-level immutable attribute on a sealed object.

Under this design, even a full remote-code-execution compromise of the write-serving daemon cannot un-write or unlock a sealed blob, because the compromised process was never granted the operating-system capability required to do so.

Problem Statement

Application-layer WORM and immutability guarantees - a database flag, an application check, even the dual-layer legal-hold enforcement described elsewhere in this portfolio - ultimately depend on the correctness of software running with sufficient OS-level privilege to write to the underlying storage medium. If that software is compromised through a remote-code-execution vulnerability, the conventional assumption that "our software refuses to un-write a sealed object" collapses, because the attacker who controls the process also controls whatever privilege the process was granted.

Existing WORM systems - object-lock cloud storage, append-only filesystems used directly - typically grant the single serving daemon whatever OS capability is required to manage retention. That daemon's compromise is, by itself, sufficient to defeat the write-once guarantee, because no separation exists between "the code that serves requests" and "the code that could un-seal an object."

Why a Single-Process Design Is Insufficient

• Cloud object-lock storage (AWS S3 Object Lock, Azure Immutable Blob): immutability enforced by the storage provider's own serving infrastructure, which must be trusted to enforce it correctly; no customer-verifiable capability-separation concept.
• Self-hosted chattr +i used directly, single process: the common pattern grants the one serving process the capability required to manage the attribute - compromise of that process is sufficient to defeat the protection.
• Hardware WORM (optical/tape): strong physical guarantees but a poor operational fit for active, network-served, queryable evidentiary systems.

Technical Architecture (As Designed)

Two-Actor Split

Sealing Sequence (as designed)

1. Write-serving daemon completes a durable write of the object's bytes.
2. Daemon signals the sidecar via local IPC that the object is ready to seal.
3. Sidecar independently verifies the object's content hash.
4. Sidecar sets the filesystem immutable bit on the object.
5. Clearing that bit - ever - requires a separate, audited administrative action outside the write-serving daemon's code path entirely; the daemon itself could never invoke it, having permanently dropped the capability at step 0.

Even total compromise of the write-serving daemon - remote code execution, a supply-chain compromise of a dependency - does not restore the capability needed to un-seal an object, because that capability was permanently dropped from that process rather than merely gated by an application-level check that a sufficiently privileged attacker could bypass.

Relationship to the Dual-Layer Legal Hold Mechanism

This protocol is a defense-in-depth complement to the dual-layer legal-hold enforcement described elsewhere in this portfolio: legal hold governs whether a delete is authorized at the application and storage-table level, while this protocol governs whether a delete is even technically possible for the component most exposed to external attack - the network-facing daemon - regardless of what authorization logic that daemon's compromised code might attempt to assert.

Prior Art Differentiation

Patent Claim