github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1720] Dropping Firejail privileges with services not running as root? #1159

New issue

Closed

opened 2026-05-05 07:33:54 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @curiosity-seeker on GitHub (Jan 9, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1720

@netblue30 once wrote:

The sandbox process runs mostly as root. After it configures the filesystem, network and seccomp it drops privileges and starts the user application.

I'm not a programmer but I guess it's done as shown here. It's evident that dropping root privileges is important to reduce the attack surface.

However, that's not done when sandboxing services like unbound. The thing is that unbound runs (at least on my Fedora system) by default under an unprivileged user unbound, and dnsmasq and dnscrpyt-proxy can be configured to run under, e.g., the user nobody. Hence, those services do not run with root permissions - but Firejail does if used to sandbox those services.

So the question is: Is Firejail running as root increasing the attack surface in those cases? And would it be somehow possible for Firejail to drop its privileges according to the unprivileged user used by the sandboxed service? If not - would it make sense to sandbox those services with systemd instead?

Originally created by @curiosity-seeker on GitHub (Jan 9, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1720 @netblue30 once [wrote](https://github.com/netblue30/firejail/issues/510#issuecomment-218789255): > The sandbox process runs mostly as root. After it configures the filesystem, network and seccomp it drops privileges and starts the user application. I'm not a programmer but I guess it's done as shown [here](http://www.insanitybit.com/2014/09/08/sandboxing-chroot-sandbox-2/). It's evident that dropping root privileges is important to reduce the attack surface. However, that's not done when sandboxing services like unbound. The thing is that unbound runs (at least on my Fedora system) by default under an unprivileged user `unbound`, and dnsmasq and dnscrpyt-proxy can be configured to run under, e.g., the user `nobody`. Hence, those services do not run with root permissions - but Firejail does if used to sandbox those services. So the question is: Is Firejail running as root increasing the attack surface in those cases? And would it be somehow possible for Firejail to drop its privileges according to the unprivileged user used by the sandboxed service? If not - would it make sense to sandbox those services with [systemd](http://0pointer.de/public/systemd-man/systemd.exec.html) instead?

gitea-mirror

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

closed this issue
added the
information_old
label

gitea-mirror commented

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

Author

Owner

@Ferroin commented on GitHub (Jan 9, 2018):

From a practical perspective, firejail running as root is probably not significantly increasing the attack surface (disclaimer: I am not a systems security expert, just a guy who has some experience dealing with securing systems). The only thing firejail not continuing to run as root could theoretically get you is the ability to have a user namespace with no UID=0, but that's already not possible because of how the setup is handled.

As far as why it does this, the programs you mentioned expect to be started as root and handle the process of dropping privileges themselves because they have things they need to do on startup that require root privileges (or more often particular capabilities, usually CAP_NET_BIND_SERVICE so that they can bind to ports below 1024). Trying to start them as a non-root user without firejail involved won't work in almost all cases, so they can't be started as a non-root user inside the firejail instance either. In theory, firejail could probably drop at least some privileges once it's started the program, but that may be more effort than it's worth.

As far as sandboxing with systemd as an alternative, you have the same issues there to varying degrees, it's just a different component that handles them (because systemd does socket activation, it can open the listening socket and hand that off to the program, but the program has to support this properly).

@Ferroin commented on GitHub (Jan 9, 2018): From a practical perspective, firejail running as root is probably not significantly increasing the attack surface (disclaimer: I am not a systems security expert, just a guy who has some experience dealing with securing systems). The only thing firejail not continuing to run as root could theoretically get you is the ability to have a user namespace with no UID=0, but that's already not possible because of how the setup is handled. As far as why it does this, the programs you mentioned expect to be started as root and handle the process of dropping privileges themselves because they have things they need to do on startup that require root privileges (or more often particular capabilities, usually CAP_NET_BIND_SERVICE so that they can bind to ports below 1024). Trying to start them as a non-root user without firejail involved won't work in almost all cases, so they can't be started as a non-root user inside the firejail instance either. In theory, firejail could probably drop at least some privileges once it's started the program, but that may be more effort than it's worth. As far as sandboxing with systemd as an alternative, you have the same issues there to varying degrees, it's just a different component that handles them (because systemd does socket activation, it can open the listening socket and hand that off to the program, but the program has to support this properly).

gitea-mirror commented

2026-05-05 07:34:01 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jan 10, 2018):

@Ferroin : Thanks a lot - your answer is very helpful and instructive as always!

Perhaps @netblue30 wants to add something before closing this issue.

@curiosity-seeker commented on GitHub (Jan 10, 2018): @Ferroin : Thanks a lot - your answer is very helpful and instructive as always! Perhaps @netblue30 wants to add something before closing this issue.

gitea-mirror commented

2026-05-05 07:34:02 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 13, 2018):

@curiosity-seeker

For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside.

The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping.

Systemd is a generic starter, with no interaction to outside world. It is more a convenience than anything else. You can use it instead of the regular starter packaged with your server, is not going to make any difference.

@netblue30 commented on GitHub (Jan 13, 2018): @curiosity-seeker For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside. The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping. Systemd is a generic starter, with no interaction to outside world. It is more a convenience than anything else. You can use it instead of the regular starter packaged with your server, is not going to make any difference.

gitea-mirror commented

2026-05-05 07:34:04 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jan 13, 2018):

Thanks again to both of you!

@curiosity-seeker commented on GitHub (Jan 13, 2018): Thanks again to both of you!

gitea-mirror referenced this issue

2026-05-05 10:09:19 -06:00

[PR #1159] [MERGED] Adds icedove directories in thunderbird profile #3864

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1159

No description provided.

Rows
Columns