[GH-ISSUE #5157] unprivileged firejail

gitea-mirror commented

2026-05-05 09:33:50 -06:00

Owner

Originally created by @rusty-snake on GitHub (May 21, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5157

Originally assigned to: @smitsohu on GitHub.

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

Originally created by @rusty-snake on GitHub (May 21, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5157 Originally assigned to: @smitsohu on GitHub. ### 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

gitea-mirror added the

enhancement

label 2026-05-05 09:33:50 -06:00

gitea-mirror commented

2026-05-05 09:33:52 -06:00

Author

Owner

@smitsohu commented on GitHub (May 21, 2022):

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.

@smitsohu commented on GitHub (May 21, 2022): 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.

gitea-mirror commented

2026-05-05 09:33:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 21, 2022):

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.

@rusty-snake commented on GitHub (May 21, 2022): > 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.

gitea-mirror commented

2026-05-05 09:33:54 -06:00

Author

Owner

@smitsohu commented on GitHub (May 21, 2022):

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 commented on GitHub (May 21, 2022): > 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.

gitea-mirror commented

2026-05-05 09:33:55 -06:00

Author

Owner

@smitsohu commented on GitHub (Jun 1, 2022):

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.

@smitsohu commented on GitHub (Jun 1, 2022): >> 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.

gitea-mirror commented

2026-05-05 09:33:56 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Jul 7, 2022):

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.

@WhyNotHugo commented on GitHub (Jul 7, 2022): 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.

gitea-mirror commented

2026-05-05 09:33:56 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 7, 2022):

No that's not what the intention here is.

@rusty-snake commented on GitHub (Jul 7, 2022): No that's not what the intention here is.

gitea-mirror commented

2026-05-05 09:33:57 -06:00

Author

Owner

@smitsohu commented on GitHub (Jul 7, 2022):

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.

@smitsohu commented on GitHub (Jul 7, 2022): > 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.

gitea-mirror commented

2026-05-05 09:33:57 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 7, 2022):

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.

@rusty-snake commented on GitHub (Jul 7, 2022): > 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.

gitea-mirror commented

2026-05-05 09:33:58 -06:00

Author

Owner

@amano-kenji commented on GitHub (Jul 8, 2022):

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

@amano-kenji commented on GitHub (Jul 8, 2022): I looked into crablock. You are the maintainer of crablock. Do you think anything can substitute for firejail in the near future?

gitea-mirror commented

2026-05-05 09:33:58 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 9, 2022):

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

@rusty-snake commented on GitHub (Jul 9, 2022): On a low level i.e. without profiles and desktop integration, yes that my goal.

gitea-mirror commented

2026-05-05 09:33:58 -06:00

Author

Owner

@Atemu commented on GitHub (Jun 8, 2023):

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": https://github.com/containers/bubblewrap/issues/412

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

@Atemu commented on GitHub (Jun 8, 2023): > 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": https://github.com/containers/bubblewrap/issues/412 Point isn't about bwrap though but rather that userns would be capable of supporting such functionality conceptually.

gitea-mirror commented

2026-05-05 09:33:59 -06:00

Author

Owner

@smitsohu commented on GitHub (Jun 9, 2023):

@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 :)

@smitsohu commented on GitHub (Jun 9, 2023): @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 :)

gitea-mirror commented

2026-05-05 09:33:59 -06:00

Author

Owner

@ghost commented on GitHub (Jun 10, 2023):

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.

@ghost commented on GitHub (Jun 10, 2023): > 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.

gitea-mirror commented

2026-05-05 09:34:00 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 19, 2024):

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 commented on GitHub (Jan 19, 2024): 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 ;)

gitea-mirror commented

2026-05-05 09:34:00 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 19, 2024):

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.

@smitsohu commented on GitHub (Jan 19, 2024): And a critical issue is of course networking. I'm aware of [slirp4netns](https://github.com/rootless-containers/slirp4netns) and [pasta](https://passt.top/passt/about), 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.

gitea-mirror referenced this issue

2026-05-05 10:23:02 -06:00

[PR #2957] [MERGED] Fix #2899 #4595

Rows
Columns

[GH-ISSUE #5157] unprivileged firejail #2899

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

Describe the solution you'd like