Skip to content

PATTERN Cited by 1 source

Minimize VM Permissions

Treat the sandbox VM's own capabilities — its network reach, its attached IAM / cloud-resource permissions, its credential lifetime, and its own lifetime — as a first-class isolation control, not a secondary one. This is the countermeasure for the case where the hypervisor boundary holds but the workload inside the VM is compromised.

(Source: sources/2026-04-21-figma-server-side-sandboxing-virtual-machines)

The underlying observation

Running untrusted or high-risk code inside a VM only protects against escape to the host. It does not prevent a compromised workload from:

  • making arbitrary outbound network requests (exfiltration, C2);
  • calling internal services with whatever credentials the VM holds;
  • persisting harmful state or further-compromised artifacts for the lifetime of the VM.

So you must narrow what the compromised VM itself can reach. Figma:

we can configure the VM's capabilities to reduce the blast radius of a malicious job taking over the VM. For example, you can (and should) restrict network access, minimize the VM's permissions to contact other services, and limit the lifetime of the VM's credentials — and of the VM itself.

Checklist

  • Network egress — default-deny; allowlist only the third-party hosts the workload legitimately needs. For Figma's link-preview Lambda, the sandbox is outside the production VPC entirely, so it has no path to internal services.
  • IAM / cloud permissions — smallest viable set; avoid "it works, ship it" permission bundles. Figma notes Lambdas are "not 'raw' compute" — they can easily be over-privileged via internal-network placement or extra IAM policies.
  • Credential lifetime — short-lived credentials (STS role, per-invoke token) rather than long-lived IAM user keys inside the VM.
  • VM lifetime — bound the VM's persistence; reuse within a tenant is a trade-off (latency vs blast-radius containment) that needs conscious choice.
  • Metadata / localhost APIs — the Lambda runtime exposes a localhost HTTP API that leaks the triggering request and accepts forged responses; any in-VM code that speaks to localhost must be audited for SSRF exposure. Figma blocks their application code from issuing localhost requests.

Figma production instance

Figma's link-metadata fetcher (ImageMagick-processing third-party URLs for FigJam link previews) runs as AWS Lambda → Firecracker micro-VM with:

  • no IAM permissions into Figma's internal services,
  • placement outside the production VPC,
  • no special privileges in the Figma AWS account.

"As this execution environment runs with no special privileges in our AWS account outside our production VPC, exploitation of vulnerabilities in our link fetching logic or in ImageMagick won't grant any ability to speak to Figma's internal services or leverage the new position to touch anything outside of the Lambda execution environment."

Relation to adjacent patterns / concepts

Seen in

Last updated · 200 distilled / 1,178 read