Confining user namespaces with SELinux

User namespaces allow unprivilegrd user apps to interact with the kernel like they normally couldnt. Access filesystem drivers, networking and more.

This opens a ton of attack surface and has resulted in a lot of exploits leading to privilege escalation to root. Actually more than root, as root users can still be SELinux confined, but the kernel has highest privileges and no protections between its components.

I found this video interesting, where 2 devs explain the issue, and how they restrict user namespace creating apps using AppArmor, to minimize this attack surface.

He also mentions the danger of allowing apps from user-writable locations to use user namespaces, as an attacker could overwrite that location.

I think secureblue has done the same here but with SELinux?

They added rules that only SELinux confined processes can create user namespaces.

They also replace suid with capabilities, see this script.

What do you think of this approach?

Even though selinux confined users are not there yet, restricting user namespaces sounds essential to me.

The situation is complicated. Firefox relies on them with no fallback apart from seccomp-bpf (which is why the Flatpak should not be promotes as secure). Distrobox, toolbx, podman, Flatpak, the whole ecosystem relies on these.

But even if the concept might not be fully flawed (which many people say), fixing this sounds crucial, to have Fedora as a leading secure distro.

It seems like Ubuntu already has this implemented, with a user facing app for troubleshooting.

This talk might interest you too

I think the ship has sailed here. The entire desktop security model is totally dependent on unprivileged user namespaces; without it, you just have no good sandboxing. I guess we could go back to using suid bwrap, but this is deprecated and surely it’s not a security win.

For desktop users, good sandboxing is the most important consideration. Users want to be confident that a compromised application cannot encrypt their home directory or upload it all to whatever country seems sketchy to you. Most people have single user systems and consider it game over if their own user account gets compromised, so kernel privilege escalation is a much lesser concern. Of course privilege escalation is still a serious problem – after all, such bugs might themselves allow escaping the sandbox! – but we should not sacrifice strong sandboxes just to defend against kernel privilege escalation.

The Ubuntu implementation is just broken. E.g. they still have not fixed the icon validator portal, so you cannot install web apps in Epiphany despite this being a known problem for 7 months. So it sure looks like Ubuntu has failed. They need to fix their allowlist.

I think an allowlist could work if it is maintained carefully, though.

P.S. Tangent: the Firefox Flatpak published on Flathub by Mozilla looks pretty good to me. I think it should stop talking directly to kcm socket and to speech-dispatcher. Those are minor flaws. I have no clue why you say it should not be treated as secure. It would be better for Firefox to use the Flatpak spawn portal to put subprocesses into separate sandboxes, like WebKit does, or like Firefox would do if running on the host system, but having one good sandbox is nevertheless commendable.

3 Likes

Hi, I agree that user namespaces cannot really be removed from the current desktops without major rewrites.

See, Android and ChromeOS dont use them. They use SELinux and mount binds for sandboxing, not exposing kernel functions like that.

An idea could also be to use fuse more, and not use the kernel for everything.

And as a rough mitigation, I will try and compile my own “modern-intel-only-laptop” kernel, simply to reduce attack surface.

Yes absolutely. I dont see how you come to the conclusion that exposing privileged kernel functions would be a good drawback here?

Exposing the kernel is like having suid binaries, if there is a vulnerability, it allows for privilege escalations. But unlike suid binaries

  • the kernel is huge and monolithic
  • it has no internal protections at all. Root users could still be SELinux confined

So what Ubuntu (and seemingly secureblue) did sounds like a good idea. Apart from rethinking the whole concept and spawning every app from a different user id.

I dont get it. They have missed one thing, the rest works but is way more secure. They miss a feature in their allowlist which may not be used that often (is Epiphany even preinstalled?).

I dont see how “they have failed”. For sure an allowlist with rules what these programs can do is work. But security is important?

Firefox tangent

The issue is (to my knowledge) that the seccomp filter used by flatpak prevents the firefox application from creating user namespaces itself. Firefox has no fork-server but just uses fork() in the code.

Chromium uses the fork server zygote which can be “rerouted” to use flatpak-spawn using zypak. Which might be reasonably fine, still pretty invasive, seeing that the Chromium sandbox is way more tested.

So Firefox Flatpak does not have user namespace isolation of processes at all. I currently run Fedora Firefox through bubblejail, which allows the isolated process to spawn user namespaces.


But still, what do you guys think about secureblue’s implementation of usernamespace protection using SELinux?

It’s a very good idea because it allows us to confine applications such that a compromised application cannot read or damage your host system.

If you think you can rewrite bubblewrap to depend only on selinux and not on unprivileged user namespaces, that might be interesting I guess? But I don’t think anybody has attempted this before.

What Firefox needs to do is use the Flatpak portal (i.e. the “Flatpak” Flatpak portal) to spawn new sandboxes for each secondary process. This is what WebKit already does.

Trying to make Firefox’s existing sandbox work under Flatpak is a dead end.

They seem to be totally unable to maintain the allowlist. Epiphany is the application I maintain, so that’s the only reference point I have to judge by. The icon validator and therefore the dynamic launcher portal is broken for all apps, and that presumably is installed by default even if Epiphany is not. This is a really simple well-understood problem; I imagine it’s probably going to be harder to deal with problems that are not well-understood. I’m not saying that an allowlist cannot work, but we would have to do a better job of maintaining ours.

1 Like