‹ BackHN Continuity

Thread

Software sandboxing: The basics (2025)

116 points · 24 comments · mococa

  1. sieve · · focus · HN ↗
    I became interested in sandboxing last month after watching LLMs fail to respect basic boundaries. Well, the very expectation that they would is foolish in the first place.

    I am not a fan of application-level sandboxing. The JVM tried with its security manager, and Deno with its allow/deny, but it is not general enough for me. At some point you have to assume that anything you run on your machine is possibly broken/compromised and then deal with the situation depending on your risk appetite.

    This is a long story that I have written about on my blog, but I decided to go down the Bubblewrap + seccomp + socat route for the sandboxing tool I built. Let's me run harnesses and compilers and even headless Firefox in sandboxes without worrying about damage to random parts of my system.

    1. JonChesterfield · · focus · HN ↗
      Highly recommend qemu instead. The sandbox machines are just more IP addresses on the local network. If you want them completely offline, put them on a network that doesn't have a route to anywhere. The sketchy AI harness is very happy with a whole machine to itself, complete with root access. You can push/pull git repos in from the outside, so all it can do is trash it's own sandbox and get reinstated from scratch by the physical machine below it.
      1. wmf · · focus · HN ↗
        VM tech has improved since then. Today you'd probably want to use Firecracker or Cloud Hypervisor with virtio-vsock instead of networking.
        1. LoganDark · · focus · HN ↗
          Surprised to see no mention of Qubes OS yet. It's somewhat like the QEMU approach but with a type 1 hypervisor (Xen).
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.