Hacker News Reader

Comment by CamJN | Hacker News Reader

You also need to block write access, so they can’t encrypt all your files with an embedded public key. And read access so they can’t use a timing side channel to read a sensitive file and pass that info to another process with internet privileges to report the secret info back to the bad guy. You get the picture, I’m sure.

View on HN

I get the picture, yes, namely that probably 99% of project dependencies don't need I/O capabilities at all.

And even if they do, they should be controlled in a granular manner i.e. "package org.ourapp.net.aws can only do network and it can only ping *.aws.com".

Having finer-grained security model that is enforced at a kernel level (and is non-circumventable barring rootkits) is like 20 years overdue at this point.

Every single big org is dragging their feet.

> You also need to block write access, so they can’t encrypt all your files with an embedded public key. And read access so they can’t use a timing side channel to read a sensitive file and pass that info to another process with internet privileges to report the secret info back to the bad guy. You get the picture, I’m sure.

Indeed.

One can think of a few broad capabilities that will drastically reduce the attack surface.

1. Read-only access vs read-write 2. Access to only current directory and its sub-directories 3. Configurable Internet access

Docker mostly gets it right. I wish there was an easy way to run commands under Docker.

E.g.

If I am running `fd`

1. Mount current read-only directory to Docker without Internet access (and without access to local network or other processes) 2. Run `fd` 3. Print the results 4. Destroy the container

This is exactly what the tool bubblewrap[1] is built for. It is pretty easy to wrap binaries with it and it gives you control over exactly what permissions you want in the namespace.

[1]: https://github.com/containers/bubblewrap

> 1. Mount current read-only directory to Docker without Internet access (and without access to local network or other processes) 2. Run `fd` 3. Print the results 4. Destroy the container

Systemd has a lot of neat sandboxing features [1] which aren't well known but can be very useful for this. You can get pretty far using systemd-run [2] in a script like this:

  #!/bin/sh
  
  uid="$(id -u)"
  gid="$(id -g)"
  cwd="$(pwd -P)"
  
  sudo systemd-run --system --pty --same-dir --wait --collect --service-type=exec \
      --uid="$uid" \
      --gid="$gid" \
      -p "TemporaryFileSystem=/:ro /tmp" \
      -p "BindReadOnlyPaths=-/bin -/sbin -/usr/bin -/usr/sbin -/lib -/lib64 -/usr/lib -/usr/lib64 -/usr/libexec" \
      -p "BindPaths=$cwd" \
      -p "PrivateNetwork=true" \
      -p "PrivateDevices=true" \
      -p "PrivateIPC=true" \
      -p "RestrictNamespaces=true" \
      -p "RestrictSUIDSGID=true" \
      -p "CapabilityBoundingSet=" \
      "$@"

Which creates a blank filesystem with no network or device access and only bind mount the specified files.

Unfortunately TemporaryFileSystem require running as a system instance of the service manager rather than per-user instance, so that will generally mean running as root (hence sudo). One approach is to create a suid binary that does the same without needing sudo.

[1] https://www.freedesktop.org/software/systemd/man/latest/syst...

[2] https://www.freedesktop.org/software/systemd/man/latest/syst...

You could also use bubblewrap [3] pretty similarly, and may not need to use sudo if unprivileged user namespaces are allowed by your kernel.

  #!/bin/sh
  
  cwd="$(pwd -P)"
  
  bwrap --new-session --die-with-parent \
      --tmpfs /tmp \
      --ro-bind-try /bin /bin \ 
      --ro-bind-try /sbin /sbin \
      --ro-bind-try /usr/bin /usr/bin \ 
      --ro-bind-try /usr/sbin /usr/sbin \
      --ro-bind-try /lib /lib \
      --ro-bind-try /lib64 /lib64 \
      --ro-bind-try /usr/lib /usr/lib \
      --ro-bind-try /usr/lib64 /usr/lib64 \
      --ro-bind-try /usr/libexec /usr/libexec \
      --bind "$cwd" "$cwd" \
      --dev-bind /dev/null /dev/null \
      --dev-bind /dev/zero /dev/zero \
      --dev-bind /dev/random /dev/random \
      --unshare-net \
      --unshare-ipc \
      --cap-drop ALL \
      --chdir "$cwd" \
      "$@"

[3] https://github.com/containers/bubblewrap

If you require network (for pnpm to install packages, etc), you also often have to add readonly access to /etc/ssl, or https wouldn't work.

It might also be helpful to just use --unshare-all, and then whitelist things you actually need (--share-net, etc).

Reply on news.ycombinator.com