I’d like to be able run code that’s potentially untrusted without risking other secrets on my machine.

  • Perhaps I’d like to try out a new package to see if it does what I want before I have to decide if I trust it or not
  • Perhaps I’d like to run a tool on some sensitive data, and I’d like to sandbox it so that even if the code is malicious it cannot leak any secrets
  • Perhaps I’d like to contribute to some project and run its build tools, but I don’t want to trust it with secrets on my machine

How can I do those things easily? Here are some approaches that I’m aware of:

  • the dev container spec (but I don’t know what the security implications are)

  • nix sandboxes its builds for reproducibility, I think

  • you can do some things ad-hoc with docker or podman

  • e.g. <code>docker run -u node -it -v .:/app node:24 yarn --cwd /app workspace server audit</code>

  • you can wrap some things with <a href=“https://justine.lol/pledge/” rel=“ugc”><code>pledge</code></a>

I would like to be able to choose what permissions to grant to various programs, something like these:

  • read/write/execute for filesystem paths
  • listening/sending on localhost
  • listening/sending on internet. Maybe granular by domain.
  • environment variables
  • maybe also communication with other processes, reading/writing other processes’ memory

Other capabilities would be neat too (camera, keyboard, etc), but solutions that can only handle the first couple of things on the list above would still be useful to me.

  • MajorHavoc@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 hour ago

    Three thoughts for you:

    1. If you’re not confident, and the stakes are high, just use a separate computer, on a different network. I’ve had my ass saved more times by my humility, than by my cleverness.

    2. Podman/Docker/Rancher does provide some security advantage, but these are not security tools. Malicious code has a history of breaking out of containers. Do not run code you expect malice from with only a container as protection. The container layer is not enough.

    3. When I’m nervous that non-root processes on my device might acccess my most valuable secrets, I take a hard look at my secret management: Does each secret serve a limited purpose? Is each secret easy and cheap to replace? Does unlocking each secret require prompting the human user? Are secrets encrypted at rest and in transit? Does unlocking secrets invoke multifactor auth? Etc.