unprivileged firejail

[rusty-snake]

Is your feature request related to a problem? Please describe.

Risk of a big SUID

Describe the solution you'd like

./configure --enable-unprivileged && ... builds a firejail version which is installed non-suid and uses unprivileged user-ns to setup the sandbox.

On systems where unprivileged user-ns got not disable a (not so small) subset of firejails features can be exposed without being SUID.

Related: #510

[smitsohu]

It certainly can be done, but it will be a significant effort. If people don't touch it because they are demotivated by the amount of effort, maybe work could be shared among several developers.

As far as I understand most of Firejails powerful network related features would not be available in an unprivileged version.

[rusty-snake]

As far as I understand most of Firejails powerful network related features would not be available in an unprivileged version.

Yes, that's the biggest block of features that are not available for unprivileged users by the kernel and requires suid-root (unless you implement a network stack in the user-space).

It certainly can be done, but it will be a significant effort. If people don't touch it because they are demotivated by the amount of effort, maybe work could be shared among several developers.

We could start with making firejail --noprofile working and look then which features needs additional work.

[smitsohu]

but it will be a significant effort. If people don't touch it because they are demotivated by the amount of effort, maybe work could be shared among several developers.

Ok, maybe I'm dramatizing a bit here :)

But some parts clearly will need to get rewritten.

[smitsohu]

As far as I understand most of Firejails powerful network related features would not be available in an unprivileged version.

Yes, that's the biggest block of features that are not available for unprivileged users by the kernel and requires suid-root (unless you implement a network stack in the user-space).

No idea how feasible or advisable that would be, but maybe network related code could be split into a separate setuid-root binary that creates and configures the network namespace and then calls a second binary for everything else. That second binary could then run without root when unprivileged user namespaces are available.

[WhyNotHugo]

Any thoughts on using bwrap for this?

It could be done progressively, for example, implementing filesystem namespacing first, and then other bits. Bubblewrap could (at least for initial implementations) be run inside the Firejail sandbox.

[rusty-snake]

No that's not what the intention here is.

[smitsohu]

Any thoughts on using bwrap for this?

bwrap can make sense if the setuid property is the starting point of your thinking.

If the starting point of thinking is that unprivileged user namespaces are not looked down upon any more in 2022, quite unlike 2015 when the first version of Firejail was released, then the limited featureset of bwrap is actually more a burden than an asset IMO.

(edit) Just to provide an example, implementing something like --private-home=.mozilla in bwrap would be quite painful; my .mozilla directory contains more than 1500 files, and all of them would have to opened in advance, and a commandline assembled such that bwrap knows how to put all of this back together again; it might not even be possible without raising RLIMIT_STACK.

[rusty-snake]

If the starting point of thinking is that unprivileged user namespaces are not looked down upon any more in 2022, quite unlike 2015 when the first version of Firejail was released, then the limited featureset of bwrap is actually more a burden than an asset IMO.

And unprivileged sandboxes can do a lot nowadays, just look at the list of (planed) features of crablock.

[amano-kenji]

I looked into crablock. You are the maintainer of crablock. Do you think anything can substitute for firejail in the near future?

[rusty-snake]

On a low level i.e. without profiles and desktop integration, yes that my goal.

[Atemu]

Just to provide an example, implementing something like --private-home=.mozilla in bwrap would be quite painful; my .mozilla directory contains more than 1500 files, and all of them would have to opened in advance, and a commandline assembled such that bwrap knows how to put all of this back together again; it might not even be possible without raising RLIMIT_STACK.

This could be solved by mounting the directory ro and then using an unprivileged overlayfs for rw.

Bwrap does not support that currently, but given that it can be implemented using a relatively simple semi-privileged wrapper script, it shouldn't be too hard to do it "properly": containers/bubblewrap#412

Point isn't about bwrap though but rather that userns would be capable of supporting such functionality conceptually.

[smitsohu]

@Atemu Another way I found in the meantime (with regards to bwrap) is to open a directory file descriptor and then do the equivalent of cp -r /proc/self/fd/<dirfd> inside the sandbox. It's pretty important though to close that file descriptor before running the untrusted task.

Point isn't about bwrap though but rather that userns would be capable of supporting such functionality conceptually.

Yes it can all be done. I tried some time ago, Firejail needs to change the way it manages privileges. Switching effective user id's all the time - like a traditional setuid program - doesn't really fly when it comes unprivileged user namespaces. Basically we need to rewrite the core logic. That's not too hard probably ... especially if a new Firejail version or flavour can raise the minimal kernel version. All that we need is finding a free week or two :)

[glitsj16]

Basically we need to rewrite the core logic. That's not too hard probably ... especially if a new Firejail version or flavour can raise the minimal kernel version. All that we need is finding a free week or two :)

I don't want to open any cans of (money) worms or such but IMHO the Firejail Project might start looking into accepting/pooling (micro-)donations and use (parts of) those resources for expert-required work like this. Hell, even independent/external auditing might be possible.

FWIW: as collaborator I don't mind doing what I do on a strictly voluntary, no-budget basis to the best of my abilities. The truly important work/efforts/invested time etcetera to improve Firejail's security blanket deserves special credit status. Not sure if this was ever considered before, but I'll dig through the issues/discussions from this perspective in the near future.

[smitsohu]

Alright, I started working on an unprivileged version that can also be be run setuid root safely, for added functionality.

It's not remotely ready for the public, but here's what I have in mind: Split what is Firejail currently into three parts. One is a libfirejail which is responsible for actually building the sandbox and starting the application. Number two is a Firejail binary that can be setuid root or not, and that for the most part just configures the library. Three is an unprivileged helper that does all the argument parsing, profile loading, globbing and so on, and that effectively translates the user supplied commands to library calls and communicates with the Firejail binary via a Unix socket. In my imagination the unprivileged helper itself can be run in a fairly tight sandbox (for example it never needs to write anything), but maybe I'm missing something. If this works out, there are a number of advantages in my eyes. First, if the library API is kept minimal, it would also work as a gentle nudge to improve overall code reuse. Second, abstracting away the low level sandbox stuff might make it easier and less scary to develop higher level sandbox features. Third, all the string parsing that Firejail does actually doesn't need any privs, and even though Firejail doesn't do any crazy things there, it would be better if it could be split out. This has in fact been proposed a long time ago in #510.

As soon as I have something that can construct a basic sandbox filesystem and do blacklist/whitelist/private options I'll come back to here, but don't hold your breath ;)

[smitsohu]

And a critical issue is of course networking. I'm aware of slirp4netns and pasta, but my impression is they all are missing the sweet spot from a Firejail perspective.

What we need is a way to filter traffic according to configurable rules, without root.