Implications of CONFIG_USER_NS

[glitsj16]

Hi, there's a debate going on in the arch linux community as to start enabling CONFIG_USER_NS for default kernels. Not the first time this is being looked at. Currently this setting is explicitly not applied to arch repo's kernels (cfr. https://bugs.archlinux.org/task/36969).

Personally I use firejail on custom kernels anyway, and I've enabled user namespaces. Just wanted to clear up any possible confusion on this topic. Hence my question, what are the implications when running firejail on a kernel that doesn't have user namespaces, if any? Or, to put it differently, does this 'cripple' firejails ability to offer its security features in any respect? To be clear, I'm not officially related to archlinux, although I consider myself to be an interested community member. Any input you or others might have on this topic is very welcome.

All the best with this much needed and simply great project,

Regards

[ghost]

When you run firejail with kernel that has disabled CONFIG_USER_NS it won't use them and you lose this security feature.

The problem with CONFIG_USER_NS is that it can be tricked to gain local root by the normal user and that's why it is disabled on Archlinux. As I know that "debate" was closed and enabling CONFIG_USER_NS in Arch won't happen.

However there is easy and secure solution to this. You can patch kernel to enable CONFIG_USER_NS only for privileged users (root). As firejail run always as root it will be able to use CONFIG_USER_NS normally.

You can add this patch to your custom kernel or use linux-hardened package which has it built-in. The same patch is used by defult for debian kernels.

[netblue30]

Good question!

There are two different technologies you can use today to setup a sandbox: SUID and user namespaces. Quite funny, both of them are terribly insecure. User namespace has the advantage when things go wrong you can blame it on kernel people. For Firejail we use SUID, at least this one we can fix ourselves.

However, we do use user namespace for a different purpose: to prevent the user from becoming root. But for this purpose we also have seccomp and capabilities. These three technologies overlap quite well, in a real world scenario it is difficult to tell which one will trigger first. You need at least one to do the job.

I would say, if Arch developers keep user namespace disabled, it will have negligible impact on Firejail users.

[curiosity-seeker]

@netblue30 : Thanks, this is a very interesting answer which helps to understand how Firejail works.

I know that your time is limited but it would be really great if you could summarize on your wordpress site (perhaps with a diagram or a spreadsheet) which technologies (e.g. which types of namespaces) are used to control what and how things interact with each other.

[Ferroin]

You may want to look at how Chromium and Google Chrome handle sandboxing, as they also use either SUID or user namespaces to be able to handle the full plugin sandboxing.

Generically though, you have:

• Mount namespaces: mount() and unmount() calls don't propagate across mount namespaces (unless you pass special flags to make it happen). This in particular means you can use overlay filesystems (or other stuff like bind mounts) to hide parts of the filesystem or make them read-only. A mount namespace is also required to be able to mount a new instance of /proc inside a PID namespace so that stuff works right.
• PID namespaces: PID numbers get remapped across a PID namespace boundary, and you can't see any processes outside of the PID namespace you're in or it's child namespaces. Mounting /proc inside a PID namespace gets you a new instance that's specific to that namespace.
• IPC namespaces: Similar to PID namespaces, but for POSIX IPC primitives (semaphores, message queues, etc). This can be used by itself, but some programs may get confused without there also being a PID namespace involved.
• UTS namespaces: One of the simplest, these just allow you to present different info from the uname command and it's various other incarnations. AFAIK, almost nothing except container software uses these.
• Net namespaces: One of the truest container technologies on this list, network namespaces essentially give you an entirely sandboxed network stack. The primary use case for them by themselves is essentially the same as VServers. While they're technically stand-alone (almost everything uses netlink these days to handle networking configuration and reporting), some tools may get confused or show bogus data if you don't also use a PID and mount namespace with a separate instance of /proc.
• User namespaces: A user namespace allows almost arbitrary remapping of UID's. This includes the ability for a user to be treated as EUID=0 inside the namespace, which is required for normal users to be able to create any other type of namespace (SUID also works, as does a combination of a handful of capabilities, but both options have their own issues). Most of the security issues arise from the fact that some things in the kernel aren't properly user namespace aware (although the number of things on that list is pretty small on current upstream kernels), which in turn means they don't properly check the UID.

Firejail uses the first three almost unconditionally. The independent networking stuff is done using net namespaces, and I'm not sure if it has code at all for UTS or user namespaces (although I think it doesn't.

[curiosity-seeker]

@Ferroin : Thanks, that's very instructive! Perhaps @netblue30 can add the missing details.

[netblue30]

I'll try to put in a description.

[glitsj16]

Great to see so much detail being provided in the replies. Exactly what was hoped for! A big thank you to all who helped clearing up possible confusion.

[polyzen]

Referencing #1842 (comment)

[chiraag-nataraj]

I'll close this for now. @glitsj16, feel free to re-open if you have more questions.