Thread

1. eranation · 1791057877 · focus · HN ↗

   Daily reminder that containers are not considered a safe security boundary, and never were. If you really need to run untrusted code, use a MicroVM.

   1. zenoprax · 1791072226 · focus · HN ↗

      It depends on your threat model but I think it&#x27;s a good reminder either way. I recently discovered SmolVM &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;smol-machines&#x2F;smolvm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;smol-machines&#x2F;smolvm&gt; and it looks like a pretty good sweet spot for usability and isolation. There are so many sandboxing technologies to pick from and understand.

      I&#x27;ve been using (rootless) Podman which gives me some basic assurances that it will stay in its designated directory and not run tools on my system directly but I have no limits on the network and with an internal UID&#x2F;GID of 0:0 I have not done myself any favours. This is the same level of protection one would implement to keep a poorly written bash script from wreaking havoc and that&#x27;s about it.

      1. binsquare · 1791074574 · focus · HN ↗

         thanks! author of smolvm here.

         I focus on being the batteries-included approach for microVMs. So network is off by default, and you can allow specific hosts (DNS is filtered too), so an agent can reach its model API and nothing else.

         And then I also put a lot of work in the jailer-style hardening around the VMM process itself: seccomp allowlist, Landlock, separate unprivileged uid per VM, and cgroup limits.

         So that users have security &amp; knobs right out of the box.

         fwiw i used to operate an AWS service using firecracker.

Unofficial Hacker News client; not affiliated with Y Combinator.