Threat model

Vesper is designed to reduce

• accidental secret disclosure through child-process environment inheritance;
• secrets appearing directly in target command arguments;
• temporary plaintext secret files;
• long-lived credentials that remain retrievable after first use;
• retrieval by unrelated processes under another UID;
• retrieval by unrelated same-UID processes when Linux process binding is used;
• inclusion of secret pages in ordinary core dumps where MADV_DONTDUMP is honored;
• inherited launcher secret pages after fork on Linux where MADV_DONTFORK is honored.

Vesper does not defend against

• root, kernel compromise or a process with effective ptrace/debug privileges;
• malicious code already loaded into the broker or authorized target process;
• a target application that logs, copies or transmits the value after retrieval;
• command history exposure caused by literal:value;
• secrets already present in the invoking shell’s own environment or memory;
• physical memory attacks or hibernation mechanisms outside normal mlock guarantees;
• denial of service by the same user, including consuming a capability before the intended thread;
• compromised build toolchains or package registries.

Important design choices

Vesper does not encrypt traffic on the local Unix socket. Confidentiality and peer identity come from filesystem permissions and kernel credentials. Adding application-layer encryption would still require a local key-distribution mechanism and would not stop a privileged local adversary.

Capabilities are opaque but intentionally present in the target environment. A token is not itself the secret; TTL, use count, UID and process scope constrain redemption. Treat capabilities as sensitive authorization material anyway.

mlock, MADV_DONTDUMP and MADV_DONTFORK are defense-in-depth calls. The program continues if the operating system refuses them, because containers and ordinary user limits often restrict memory locking.

Audit logs include secret names and process metadata but never values or capability tokens. Deployments where names are sensitive should omit --audit.

Исходник