Homebrew's security model on Linux and a prototype of an alternative setup

[HastD]

I've been thinking about Homebrew's security model on Linux; I have an idea (with a working prototype) of an alternative model, and I'd love to get feedback and see if there's interest in incorporating any of it (concept and/or implementation) into Homebrew.

Currently, the Homebrew installation at /home/linuxbrew/.linuxbrew is owned and exclusively writable by the user who installs it. Homebrew build/install scripts can, in principle, run arbitrary code; recent developments with Linux sandboxing are great, but sandboxing is a hard problem in general, and it's currently not all that strict of a sandbox (for example, it doesn't look like it has a very restrictive seccomp filter). And in the opposite direction, any unsandboxed process run by the same user can modify the Homebrew installation, same as that user's other files. (Contrast with packages installed by a typical Linux package manger like dnf, apt, pacman, etc., where root access is required to modify installed packages.)

My idea is to instead have the Homebrew installation owned by a dedicated linuxbrew system user, in combination with a DBus service that allows any authorized user to request brew commands be run. I've implemented this here. For comparison, with this setup:

• /home/linuxbrew/.linuxbrew is owned by and exclusively writable by the linuxbrew user, and readable by all users.
• Any user can request brew commands to be run as linuxbrew via a brew-proxy executable, which communicates over the DBus system bus with a daemon run by linuxbrew; command output is transparently relayed back to the user. Authorization is managed by Polkit, and Polkit policy determines which users have to authenticate for which commands.
• Standard Unix permissions prevent brew install and similar commands from having access to users' home directories. Additionally, the daemon runs with systemd sandboxing options, which can provide a seccomp filter, restrict access to various system resources and interfaces, and so on, similar to what bwrap can do but not requiring the system to allow unprivileged user namespace creation (since the sandbox is set up by the system service manager).

This seems to me to be a substantial security improvement, plus it's compatible with multi-user setups. However, it does have limitations/downsides: while the core brew functionality (e.g. installing, uninstalling, and updating packages) works smoothly, some other functionality runs into problems. (For example, brew bundle doesn't work with this yet, though I have an idea and am working on it. It also doesn't support brew developer commands yet.)

If there's interest, I'd certainly rather work with the Homebrew developers on this idea to have something along these lines upstreamed. Thoughts/feedback?

[p-linnane]

Thanks, and nice work prototyping this. Worth noting we shipped a default Linux build sandbox in Homebrew 6.0.0 today (bwrap, covering build/test/postinstall, aligning Linux with macOS), so the general "add sandboxing" gap is mostly closed now.

The part of your approach that's still distinctive is the bit you flagged yourself: systemd service sandboxing doesn't depend on unprivileged userns, which is exactly where bwrap is weakest on hardened distros. A userns-independent sandbox path, decoupled from the ownership/multi-user changes, is the piece I'd find interesting.

The ownership/multi-user side can't go upstream regardless. Multi-user is explicitly Unsupported (https://docs.brew.sh/Support-Tiers), by policy not oversight, and brew-proxy is a wrapper, which is the right home for it. nix-homebrew sits at Tier 3 for the same reason.

[HastD]

Thanks for the response; I'm certainly glad to see the Linux sandbox ship. Actually, I do have a question about that: Is there somewhere where the sandbox parameters are documented aside from just directly reading the source code? I'm not familiar enough with Homebrew's codebase to be confident in my reading of it, and I'd like to know what exactly it denies access to, what seccomp filter it uses, and so on.

I do think the security boundary provided by running under a separate user account is stronger than a userns-based sandbox unless that sandbox also includes a fairly restrictive seccomp filter or something along those lines; I'm thinking, for example, of how a number of permissions associated with the flatpak sandbox (which also uses bwrap) can be used as sandbox escapes.

I'm actually not sure what's the best way to do unprivileged, userns-independent sandboxing on Linux. I don't think the systemd sandboxing I set up for brew-proxy would work with a systemd user service: the reason brew-proxy doesn't need unprivileged userns is because the systemd system service manager (which runs as root) handles sandbox creation, and a user's systemd session service manager has the same restrictions on userns creation as the user.

I suppose one possibility would be to set up something like brew-proxy where the daemon is still started as a system service but run as the user who installed brew rather than as a separate linuxbrew user. It feels a little silly to have a user communicate with themselves via DBus using the system bus rather than the session bus, but it would work. (And I know Homebrew has chosen not to support multi-user setups, but you could get some level of multi-user functionality basically for free this way if you configure Polkit so the brew owner doesn't have to authenticate but all other users do.) Not sure if this idea is worth pursuing further.

Another option that I tried out before I got the idea for brew-proxy was to use Syd to sandbox Homebrew; it's an unprivileged sandboxing tool that doesn't rely on user namespaces and primarily uses Seccomp and Landlock to be able to set up sandboxes in a pretty fine-grained way. (I still have a Syd profile for Homebrew sitting around; I can post it somewhere if you want to give it a try, though I'm not using it anymore and haven't tested it all that extensively.)