Security model

This is a summary of the product’s security model for 0.8.0 (0.7.1 plus what 0.8.0 adds). To report a vulnerability, see below.

What it is for

Antinomie runs Linux samples you choose in QEMU virtual machines on your own computer and records what they do from inside the guest kernel. It is a tool for analysts who are allowed to handle the samples they run. It is not a containment product, and it assumes the computer it runs on may be lost to a sample one day.

Run it on a dedicated analysis computer, or at least a dedicated user account, with KVM. Keep nothing on that account you would mind a sample reading: no SSH or GPG keys, browser profiles, cloud or work credentials, source checkouts with tokens, or other people’s data.

What runs where

Antinomie needs no root; everything runs as your user. The one exception you choose yourself is building a base with Docker, which needs the root-equivalent docker group; Automatic tries Podman first.

Component	Where it runs	Handles hostile data
Host app: UI, recorder, transport client, route gateway	Your user, no sandbox	Telemetry from the guest kernel; on Routed VMs, the guest’s network frames and, with a Cloud VPS profile, its metadata requests
QEMU	Your user, no extra sandbox	Everything the guest does
Patched guest kernel with the recorder	Inside the VM	The sample, on the same machine
Static analysis, properties and detection workers	bubblewrap	Specimens, recordings, captures
TShark	bubblewrap and `prlimit`, as user 65534	Packet captures
Disk browser, `qemu-img` for imported images, MemNixFS	bubblewrap (and `prlimit`)	Disk images, memory dumps
Volatility 3	Your user, no sandbox	Memory dumps
gdb console (GEF or pwndbg)	Your user, cleared environment, private home	The debugged guest process
Open in Wireshark	Your user, no sandbox	The capture

The bubblewrap profile and the transport are described in How Antinomie works. No host folder is shared into the guest; files reach it only through an upload.

What a sample can and cannot do

Inside the guest it can do whatever its account allows. Programs run as Normal user (UID and GID 1000) unless you pick Root. On Debian bases that account has password-protected sudo.
With guest root or a guest kernel exploit it runs at the recorder’s level and can stop, blind or falsify the telemetry and anything else the guest reports. Treat everything after a sample gains root as unreliable evidence.
Escaping QEMU is QEMU’s and KVM’s boundary, not something Antinomie can prevent. QEMU runs as your user, so an escape gets your user’s access: the data directory (API keys, other samples, recordings) and whatever else the account can read. Keep QEMU and the host kernel updated.
The host-side tools read hostile data, which is why most run in bubblewrap. Volatility, the gdb console and Wireshark do not.
Over the network it can reach whatever its VM’s network mode and the run’s route allow. NAT is the least isolated mode: the guest can reach the Internet, your local network and services on the host’s loopback interface. See Network isolation.

What the app contacts

Downloads use curl with HTTPS only, also across redirects, and ignore your ~/.curlrc.

First launch. The Getting started window reads the base catalog index from the antinomie-bases bucket on Hugging Face.
Volatility symbol tables. For a memory dump without its own symbol table, Volatility looks one up on GitHub. This is on by default; the Memory tab has the switch.
Only when you ask: bases and base builds, analysis tools, Tor and wireproxy, the rule catalog and packs (also off until you allow downloads), abuse.ch datasets, MalwareBazaar and MalShare searches and downloads, IOC Check online (off at every start), the Test buttons, and Tor itself when a run uses the Tor route.

Antinomie does not upload your evidence. Bases are checked for size and SHA-256 against the catalog; analysis tools, Tor and wireproxy against SHA-256 values pinned in the source. No signature is checked on the base catalog itself.

Sensitive data

Treat the data directory, and everything exported from it, as both malware and confidential material.

Recordings are full-content: buffers, terminal transcripts, and in 0.8.0 the earlier content of files the runs changed. See Recordings contain secrets.
Malware is on disk: the specimen kept by static analysis (unencrypted), unpacked layers, dumps, cores, captures, and exports.
The sample library New in 0.8.0 keeps every sample you add, download or upload (up to 256 MiB) as an owner-only AES zip with the password infected, decrypted only in memory. Its database holds names, tags, origins (including the host path an upload came from) and the custody log.
Reports New in 0.8.0 are owner-only (0600). The evidence bundle’s outer .zip is not encrypted; the dropped files are in an inner AES-256 archive with the well-known password infected, which stops accidental opening and scanning, not reading.
The custody log New in 0.8.0 is tamper-evident, not tamper-proof; keep the head hash elsewhere. Signing uses your own minisign or SSH key; Antinomie has no key of its own, never reads the key file and never asks for a passphrase.
Secrets Antinomie keeps, each readable by you only: API keys, the SOCKS5 password, Tor’s data folder and, per Debian VM, the guest account’s salted password hash.

See Handling samples on the host.

Stealth limits

A stealth profile changes what the guest can read of its hardware identity, and current bases keep the guest kernel’s own traces out of view. It does not make the VM undetectable: the Still visible list names what remains, CPUID and RDTSC checks are not recorded, and software breakpoints are bytes a sample can read. A Cloud VPS profile leaves the hypervisor flag visible on purpose, and its canary credentials contain ANTCANARY. Assume a sample can tell it is being analysed.

Checklist before running a sample

A dedicated computer or account with no keys, credentials or other people’s data, on a host you can rebuild.
KVM, with QEMU and the host kernel kept up to date.
Tools → App dependencies (or antinomie --check-dependencies) shows bubblewrap working.
The VM on Disconnected or Isolated; if the sample needs a network, Routed with None (drop) or InetSim.
NAT or a live route only on purpose.
Normal user unless the analysis needs root.
No real credentials typed into the guest.
Afterwards, reset the VM’s disk or restore a snapshot, and handle exports and evidence bundles as malware.

Reporting a vulnerability

Do not open a public issue for a vulnerability. Report it privately through GitHub: the repository’s Security tab, Report a vulnerability (new advisory). Include the Antinomie version (antinomie --version), the base name and revision, the host distribution, the affected component and its impact, and steps or a minimal reproducer. Prefer a harmless program over live malware; if a real sample is needed, give its SHA-256 instead of attaching it.

Version	Supported
0.7.x (latest release)	Yes
`release-*` development branches	Fixes land there first; not a supported release
0.6.x and earlier	No; upgrade to the latest release

Expect an acknowledgement within 7 days and an assessment, with a planned fix for a confirmed issue, within 30 days. Fixes ship as a patch release with a GitHub security advisory, and reporters are credited unless they ask not to be. Please allow time for a fix before disclosing; 90 days is the default.

In scope: a guest program reaching the host through Antinomie’s own code, bypassing the analysis sandbox, a route sending traffic somewhere other than documented, unchecked downloads, and secrets written where the documentation says they are not. Out of scope: escapes from QEMU or KVM themselves (report them to QEMU or your kernel vendor), a sample detecting Antinomie, guest root tampering with its own telemetry, and bugs in third-party tools Antinomie can install. The full policy is in SECURITY.md.