Relevancy of user separation for sandboxing

[odomingao]

Hello!

I've been looking at isolation solutions in Linux, and I stumbled into this quote from the Kicksecure wiki:

"Sandboxing programs running as the same user has historically, never seriously worked well. It’s been the cause of many issues with e.g. Flatpak. It’s why Android/iOS have always used separate users."

This quote seems to be 4 years old. Is it still preferable to run sandboxed programs as their own user if possible, using e.g. sudo or machinectl? What are some potential pitfalls of not doing so?

Thank you.

[igo95862]

Hello @odomingao

The obvious downside is that you will have to have some kind of privilege elevation like sudo in order to use different user to sandbox. This elevation tool can have vulnerabilities of its own which will run as root because of nature of SUID programs.

Also sharing folders will become very problematic as all files will belong to a different user.

[rusty-snake]

This elevation tool can have vulnerabilities of its own which will run as root because of nature of SUID programs.

The tool can be as small as newuidmap or as SUIDless as run0.

Also sharing folders will become very problematic as all files will belong to a different user.

Using acls this is the smallest problem. Some software listening on unix sockets (e.g. wayland) checks the process credentials of clients in their code. Either disable this security check altogether or find more complicated ways. Actually you would need something like a wayland-proxy (If anyone is interested in this, look at firefox codebase).

[rusty-snake]

Is it still preferable to run sandboxed programs as their own user if possible, using e.g. sudo or machinectl?

Yes. Users are the privilege separation ground every nix* of the last 40 years is build on.

Not necessarily su(do)/pkexec/systemd/run0/machinectl. Even unprivileged podman can change the uid.

What are some potential pitfalls of not doing so?

Sharing resources and accessing APIs:

• Files
• Wayland
• D-Bus
• PipeWire
• Pulseaudio
• KeePassXC / ssh-agent / gpg-agent
• ...

Opening access to them removes already 50% of what you win with a different uid. Ideally you run a full sandboxed session for every program.
gnome-shell/mutter were technically good in nested usage. However it is very inconvenient unless you have only a handful of nested session that don't need to share resources between them. I want to have an setup with at least all my development tools running in a sandboxed nested session that forwards single windows rather than full single desktops (like QubesOS). But more than subuid and setuid integration in crablock is not done yet.

TL;DR:

• If you have a system daemon (e.g. dnsmasq, caddy, ...) use systemd's User=/DynamicUser= directives or the building user drop of the program.
• If you have some cli tools with high-risk, long-running, isolated (in terms of e.g. files) workload, you may consider to run0 or whatever to a different uid.
• If you want to sandbox desktop programs like firefox, don't brick your setup.
  • The win compared to the what could I do wrong (not only bricking, also opening vulnerabilities) is not worth it.