branderson
d2d00dba90
Two claims in docs/threat-model.md were false rather than loose. An escape would be a downgrade, and the account already holds more than the escape would grant: root on the VM is strictly more capability than a process inside a container with a trimmed capability set. Root on this VM is already a row in the blast radius table, which is the case the model is drawn around, and the hypervisor firewall bounds it identically however root was reached. The escape section names what an escape reaches that the container did not, and it is not one thing. Every other project on the box becomes readable, and uncommitted work in those exists nowhere else. Beyond that, the model API credential: dejima keeps it out of the container deliberately, so a session can use the API while it runs and cannot carry the token away, and the proxy holding it runs on the devbox. That makes an escape onto the devbox the step that turns temporary use into a token someone keeps. It is not the only loss that reaches past the machine, and no longer says so. Source and uncommitted work leave just as easily. What puts the credential first in the queue is that it is a standing capability rather than a copy of data, and that it sits at a known path under a known name, which makes it among the easiest things on the box to find. That also corrects the rootless rejection, which claimed the set it would protect was close to empty. It is small but not empty, and the control covers neither half of it: the proxy runs as whichever account runs the session, and one account owns every project, so moving the session to a dedicated account moves the projects with it. The threat model no longer rests on the adversary being unsophisticated. Real supply-chain malware fingerprints its environment, stages, beacons and can hand a session to a person, and a prompt injection borrows the agent as its adaptive component. What the model rests on instead is that every one of those moves needs egress, which the node firewall bounds whether the thing being bounded is a script or a person driving it. Being undirected changes what is likely, not what is possible. One person's work per devbox is stated as a requirement of the threat model rather than an observation, and cross-project context poisoning is stated as handled in dejima, in the present tense.
2.1 KiB
Security policy
What dejima-devbox-hardener claims
It bounds what a compromised developer VM can reach on your network, and reports what that bound is.
On your network is the whole of the claim. It does not bound egress to the internet, and nothing on the VM does: outbound traffic to public addresses is permitted by design. Exfiltration and command-and-control are out of scope, and a compromise here can phone home. What is bounded is where it can spread.
It does not prevent root on that VM, and nothing here tries to. It does not make running agent-authored code safe. It does not roll anything back: unlike a CI runner, a devbox holds uncommitted work, so there is no scheduled undo and no state this tool restores.
The controls are the hypervisor firewall, which this repository documents but cannot apply from inside the guest, and an audit that verifies the firewall by behaviour because the rules live where the guest cannot read them.
docs/threat-model.md states what each layer grants, and which stronger options were rejected and why.
This is not proven software
These projects are in early development. Nothing in them has been through outside review, an external audit, or adversarial testing by anyone other than the people who wrote them. Where a design argument is stated it is one person's reasoning; where a test asserts something it asserts what that person thought to check.
Treat every security property described in any of these repositories as a claim awaiting scrutiny rather than one that has survived it, and do not deploy them where being wrong would matter.
Reporting a vulnerability
Email dejima@branderson.io. Please do not open a public issue for a vulnerability; the tracker is public, and a report there is a disclosure.
Useful things to include:
- what an attacker gets;
- the steps to reproduce it;
- the commit you tested.
The rest of the policy
What is promised in return, the support position, supported versions and warranty are set once for the whole organisation and are not restated here:
https://gitbox.branderson.io/dejima/dejima/src/branch/main/SECURITY.md