Arch Linux

maklor

Member

Registered: 2020-03-20

Posts: 5

User namespaces vs suid assessment

After several years in doing research regarding linux hardening, sandboxing and namespaces I am at a point where I am still having trouble assessing the benefits of certain features or measures.

Some time back I contributed significant time to the development of firejail, however as an suid application that never drops privileges for good, using this sandbox seemed like a risky choice and several privilege escalation vulnerabilities have confirmed this. The design has not changed to this day which is why I am no longer using this.

On thing I have been using for some time is flatpak for its sandboxing features, especially for webbrowsing.
The sandboxing features in flatpak are implemented by bubblewrap, which has a way better approach to its own security, dropping privileges permanently after getting a user namespace.

Recently user namespaces, which had and continue to have planty of security issues itself, have become available for unprivileged users in arch linux, as well as many other distros.
As a result bubblewrap now comes without suid by default, eliminating all potential security issues with suid altogether.

However the availability of unprivileged user namespaces has opened another can of worms.

The linux-hardened kernel has unprivileged user namespaces disabled by default (for good reason) but required bubblewrap to be run with the suid bit again.

In addition, many other applications nowadays use the unprivileged user namespaces for sandboxing, such as chrome, firefox and all electron based applications.

The question is what to do: running linux-hardened with unprivileged user namespaces disabled, requireing bubblewrap (and others such as chrome) to run with suid and indirectly disableing sandboxing features in other applications like firefox as well. Or having the huge attack surface of unprivileged user namspaces but being able to use all sandboxing features that use this?

I would appreciate any thoughts and inputs on this issue.

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: User namespaces vs suid assessment

I'd trust a setuid sandbox over unprivileged userns sandboxes, because setuid applies to one binary (bwrap, or chrome-sandbox) which is carefully vetted and designed by people who know a lot about security. Whereas once you let unprivileged userns loose, it is by definition unprivileged and anyone can use them.

Chrome and electron packages already ship with a setuid chrome-sandbox binary, because they must work on linux-hardened or systems with the sysctl set to disable unprivileged userns. bubblewrap and bubblewrap-suid differ only in that one is chmodded to have suid, and it's unclear what the purpose of having two packages is.

Either sandboxing mechanism is doing the same thing: irrevocably dropping root privileges as soon as possible with the least amount of code being run as EUID 0, while setting up a user namespace for later use by the sandbox. Either application is perfectly safe; the only question is whether you think that allowing random binaries compiled on the spot by user foobar, to *also* have userns access, is safe.

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

maklor

Member

Registered: 2020-03-20

Posts: 5

Re: User namespaces vs suid assessment

The applications using native sandboxing, only isolate their high risk proccess childs, like the rendering processes.
This is generally good, however if you want to e.g. isolate all your local files from your browser process in general, you need a separate sandbox, such as the ones bubblewrap/flatpak provide.

The best case would be to disable unprivileged userns and at the same time have both the "wrapper" sandbox aka bwrap as well as the "native" sandbox that ships with chrome, firefox, electron and so on.

However, if bwrap is run with suid, the native sandbox of electron for example won't be able to run, since the use of suid is blocked inside a bwrap sandbox

https://github.com/containers/bubblewrap/issues/132

FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/electron/chrome-sandbox is owned by root and has mode 4755.

That means when running bwrap with suid, electron apps can only be run with the option --no-sandbox, disableing the native sandboxing features.

With unprivileged userns available both the bwrap sandbox and the native sandbox work fine, making this choice even harder.

maklor

Member

Registered: 2020-03-20

Posts: 5

Re: User namespaces vs suid assessment

Just to be clear, I generally do agree with your assessment.

The only things that keep me thinking about this is the issues with the native (suid) sandboxing mentioned above as well as recent privilege escalation in bwrap https://github.com/containers/bubblewra … -rvxj-43vj that again show how suid is risky

latalante1

Member

Registered: 2018-08-30

Posts: 110

Re: User namespaces vs suid assessment

Maybe setuid sandbox in chrome is needed for Debian stable with the 3.16.x kernel.

Chrome launched in this way says: "You are adequately sandboxed".

systemd-run -G --user -p NoNewPrivileges=yes /usr/bin/google-chrome-stable