Security: Guest agent exposes raw private keys to all local processes

[kvinwang]

Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-2j2p-pgfg-h6vp by @pbeza.

Root Cause

The guest agent's get_key RPC endpoint returns raw secp256k1/ed25519 private key bytes over a shared Unix socket (/run/dstack/guest-agent.sock). The derivation path is entirely caller-controlled, there is no authentication, no per-container isolation, and no rate limiting. Any process that can access the Unix socket can derive arbitrary keys, including the signing key used for VM identity (path "vms").

Attack Path

1. Attacker compromises any container running inside the CVM (e.g., via a web application vulnerability)
2. Compromised container connects to /run/dstack/guest-agent.sock
3. Attacker calls get_key with path = "vms" and algorithm = "secp256k1" to get the VM signing key
4. Attacker calls get_key with arbitrary paths to derive additional keys
5. Attacker now holds private keys that can impersonate the CVM or sign arbitrary messages

Impact

Any compromised container in the CVM can extract all derived private keys. The guest agent provides no isolation between containers — a vulnerability in any workload running in the CVM gives the attacker access to all cryptographic keys, including the VM identity key.

Suggested Fix

1. Implement per-container key isolation — derive keys using a container-specific context (e.g., container ID or cgroup path)
2. Add access control on the Unix socket (e.g., per-container sockets with different permissions)
3. Consider returning only public keys and providing a sign operation instead of exposing raw private keys
4. Add rate limiting to prevent key enumeration

---

Note: This finding was reported automatically as part of an AI/Claude-driven internal audit by the NEAR One MPC team. It has not been manually verified by a human to confirm whether it constitutes an actual security issue.

[kvinwang]

Maintainer response (copied from private security advisory GHSA-2j2p-pgfg-h6vp):

Thank you for the report!

This is by design, not a vulnerability.

dstack's threat model: the CVM is a single trust domain

dstack treats the entire CVM as a single trust domain. All containers within a CVM run the same app-compose (docker compose), and the compose file is measured into RTMR3 (via compose-hash). The CVM is not designed for multi-tenancy — all workloads inside a CVM belong to the same application and share the same trust boundary.

In this model, all containers within the CVM are equally trusted. The guest agent socket /run/dstack/guest-agent.sock is intentionally accessible to all containers because they are all part of the same attested application.