4 ms·

See also Bubblewrap[1]. I use Bubblewrap all the time, because it's just useful, and a bit easier than doing things with unshare directly. To compare and contr

by jchw 3y ago

See also Bubblewrap[1]. I use Bubblewrap all the time, because it's just useful, and a bit easier than doing things with unshare directly. To compare and contrast: bubblewrap is lower level, and is great for embedding or using in one-off invocations, whereas firejail is more oriented towards adding a bit of hardening to everyday applications like Firefox via built-in and custom profiles. For example, you could temporarily override a path doing something like this: bwrap --bind / / --bind /tmp/myoverride /usr/lib/qt5.15.2/plugins/kf5 -- ... to, say, override the KDE plugins while testing. This is useful for me since it's rather challenging during development to actually get KDE apps to reliably load my plugins on NixOS: I think kio slaves are probably wrapped and getting other environments injected into them. Rather than bother with any tricky hacks, Linux namespaces make it relatively easy to test regardless. Bubblewrap is used internally by Flatpak and others. https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap

5e92cb50239222b 3y ago
I've been using it to wrap nodejs package managers in response to all malware shipped through them over the past few years. A simple wrapper script like this works fine (symlinked to `npm`/`yarn`/`pnpm` into whatever directory is the first in $PATH): bin=$(basename "$0") exec bwrap \ --bind "$PWD" "$PWD" \ --dev /dev \ --die-with-parent \ --dir /tmp \ --dir /var \ --disable-userns \ --new-session \ --proc /proc \ --ro-bind /etc/ca-certificates /etc/ca-certificates \ --ro-bind /etc/resolv.conf /etc/resolv.conf \ --ro-bind /etc/ssl /etc/ssl \ --ro-bind /usr /usr \ --setenv PATH /usr/bin \ --share-net \ --symlink /tmp /var/tmp \ --symlink /usr/bin /bin \ --symlink /usr/lib /lib \ --symlink /usr/lib64 /lib64 \ --unshare-all \ --unshare-user \ "/usr/bin/$bin" "$@" It gets read-write access to the current path, and to its own copy of ~/.cache and ~/.local/share. It doesn't see anything else from your home directory, including any adjacent projects. It can easily be locked down further by allowing read-only access to the project, and read-write access to node_modules and nothing else.
- agucova 3y ago
  I'm confused, how would this prevent supply chain attacks? Wouldn't you need to sandbox node itself, instead of npm?
  - lapinot 3y ago
    It does not, supply chain attack is not that afaik. This is to defend against npm executing arbitrary nefarious code as your user on install of a compromised package. Also sandoxing npm really means sandboxing node running npm (which is js).
  - jchw 3y ago
    My understanding: It's sandboxing to protect against exploits delivered via supply chain attacks, which often use low hanging fruit like hooks on install to steal tokens/etc. It's definitely not perfect, but it does not hurt either.
- totallywrong 3y ago
  Is there any advantage to using this over a container with bind mounts?
  - jchw 3y ago
    node-gyp/C extensions will work with whatever you have installed, which is a nice plus. In containers you obviously only start with what is in the OCI image, and the node_modules will probably not work in the host machine unless the container closely matches the host environment.

by jchw 3y ago

5e92cb50239222b 3y ago

I've been using it to wrap nodejs package managers in response to all malware shipped through them over the past few years. A simple wrapper script like this works fine (symlinked to `npm`/`yarn`/`pnpm` into whatever directory is the first in $PATH): bin=$(basename "$0") exec bwrap \ --bind "$PWD" "$PWD" \ --dev /dev \ --die-with-parent \ --dir /tmp \ --dir /var \ --disable-userns \ --new-session \ --proc /proc \ --ro-bind /etc/ca-certificates /etc/ca-certificates \ --ro-bind /etc/resolv.conf /etc/resolv.conf \ --ro-bind /etc/ssl /etc/ssl \ --ro-bind /usr /usr \ --setenv PATH /usr/bin \ --share-net \ --symlink /tmp /var/tmp \ --symlink /usr/bin /bin \ --symlink /usr/lib /lib \ --symlink /usr/lib64 /lib64 \ --unshare-all \ --unshare-user \ "/usr/bin/$bin" "$@" It gets read-write access to the current path, and to its own copy of ~/.cache and ~/.local/share. It doesn't see anything else from your home directory, including any adjacent projects. It can easily be locked down further by allowing read-only access to the project, and read-write access to node_modules and nothing else.

agucova 3y ago
I'm confused, how would this prevent supply chain attacks? Wouldn't you need to sandbox node itself, instead of npm?
- lapinot 3y ago
  It does not, supply chain attack is not that afaik. This is to defend against npm executing arbitrary nefarious code as your user on install of a compromised package. Also sandoxing npm really means sandboxing node running npm (which is js).
- jchw 3y ago
  My understanding: It's sandboxing to protect against exploits delivered via supply chain attacks, which often use low hanging fruit like hooks on install to steal tokens/etc. It's definitely not perfect, but it does not hurt either.
totallywrong 3y ago
Is there any advantage to using this over a container with bind mounts?
- jchw 3y ago
  node-gyp/C extensions will work with whatever you have installed, which is a nice plus. In containers you obviously only start with what is in the OCI image, and the node_modules will probably not work in the host machine unless the container closely matches the host environment.