Always run third-party code (especially npm packages) inside a sandbox, take your pick: ai-jail, bubblewrap, seatbelt, or amazing-sandbox (the last one, I wrote for myself after trying all others).
Bubblewrap doesn't help with protecting DBus bus (and you can do a lot with unrestricted access to DBus), accessing the GPU, Wayland and audio daemon. It cannot protect /proc and /sys filesystems. So it works only for simplest CLI programs.
As I remember, some Node.js utility (maybe npm) had a bug where it hang if there were no /proc filesystem because it couldn't figure out how many CPUs are available. Telegram crashes because of Apple's Grand Central Dispatch library if run in a sandbox without /proc. That's how bad things are.
Also, Chrome and Electron apps use SUID binaries to build their own sandbox. How would you sandbox an Electron app (obviously running an untrusted SUID binary is not an option)?
This seems to have similar or less features than bubblewrap, but requires Docker which loads huge images and wastes disk space. No Wayland, DBus, Pipewire, proc, sys filtering. Furthermore, Docker docs explicitly says that it cannot be used for security sandboxing. Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.
> Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.
You can run it without root.
And that's what you should do.
> No Wayland, DBus, Pipewire, proc, sys filtering.
Yeah, I don't need Wayland for CLI tools.
For others, you get them inside Docker, isolated from the rest of the system.
When I run `npm install`, I want isolation.
