github-starred/firejail

Fork 0

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

[GH-ISSUE #5827] Allow `--caps.keep` and newprivs for `--chroot` #3103

New issue

Open

opened 2026-05-05 09:44:25 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 09:44:25 -06:00

Owner

Originally created by @azurvii on GitHub (May 12, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5827

Description

I read from the manpage of the version I use (0.9.72 from debian bookworm) for --chroot: If the sandbox is started as a regular user, nonewprivs and a default capabilities filter are enabled..

It seems these are not just default but enforced with no option to alter. e.g. I could not apply --caps.keep:

firejail --noprofile --chroot=$HOME/myjail --caps.keep=sys_admin bash
Error: all capabilities are dropped for chroot by default.
Please remove --caps options from the command line.

My ask is to allow people to use these flags in chroots. If the security risk is high, making another mandatory flag (like --i-like-danger) just to confirm that the user would know what they are doing, to allow this combination to work.

I found a similar/same issue, #3567. Though my target program of issue is podman, vscode/other chrome-based apps. Chrome-based apps could use no sandbox as a workaround, but not all apps have alternatives.

Originally created by @azurvii on GitHub (May 12, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5827 ### Description I read from the manpage of the version I use (0.9.72 from debian bookworm) for `--chroot`: `If the sandbox is started as a regular user, nonewprivs and a default capabilities filter are enabled.`. It seems these are not just default but enforced with no option to alter. e.g. I could not apply `--caps.keep`: ``` firejail --noprofile --chroot=$HOME/myjail --caps.keep=sys_admin bash Error: all capabilities are dropped for chroot by default. Please remove --caps options from the command line. ``` My ask is to allow people to use these flags in chroots. If the security risk is high, making another mandatory flag (like `--i-like-danger`) just to confirm that the user would know what they are doing, to allow this combination to work. I found a similar/same issue, #3567. Though my target program of issue is `podman`, vscode/other chrome-based apps. Chrome-based apps could use no sandbox as a workaround, but not all apps have alternatives.

gitea-mirror added the

enhancement

label 2026-05-05 09:44:25 -06:00

gitea-mirror commented

2026-05-05 09:44:27 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 12, 2023):

This would allow privilege escalation.

@rusty-snake commented on GitHub (May 12, 2023): This would allow privilege escalation.

gitea-mirror commented

2026-05-05 09:44:28 -06:00

Author

Owner

@azurvii commented on GitHub (May 13, 2023):

That is what I asked in the title. But I may not have the insights you implied in the sentence.

Could you help to expand a bit more on that, as in how much different are the options used in a regular firejail jail comparing to a firejail chroot?

@azurvii commented on GitHub (May 13, 2023): That is what I asked in the title. But I may not have the insights you implied in the sentence. Could you help to expand a bit more on that, as in how much different are the options used in a regular firejail jail comparing to a firejail chroot?

gitea-mirror commented

2026-05-05 09:44:29 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 13, 2023):

It would allow every process that can start firejail to become root.

@rusty-snake commented on GitHub (May 13, 2023): It would allow every process that can start firejail to become root.

gitea-mirror commented

2026-05-05 09:44:30 -06:00

Author

Owner

@azurvii commented on GitHub (May 16, 2023):

You mean on the host anyone could invoke firejail --chroot to obtain root, if caps and newprivs are allowed? How to achieve that if the given options are available?

@azurvii commented on GitHub (May 16, 2023): You mean on the host anyone could invoke `firejail --chroot` to obtain root, if caps and newprivs are allowed? How to achieve that if the given options are available?

gitea-mirror commented

2026-05-05 09:44:31 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 17, 2023):

A the point where you can run host-suid with a manipulated root there are just to much ways that you could implement this in a safe way.

Possible exploit ideas contain opening file-descriptors before starting firejail or passing them over a Unix socket, tampering with system libraries or the dynamic linker, ...

@rusty-snake commented on GitHub (May 17, 2023): A the point where you can run host-suid with a manipulated root there are just to much ways that you could implement this in a safe way. Possible exploit ideas contain opening file-descriptors before starting firejail or passing them over a Unix socket, tampering with system libraries or the dynamic linker, ...

gitea-mirror commented

2026-05-05 09:44:32 -06:00

Author

Owner

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

I found some examples here, of using chdir() and open file descriptor with root inside chroot, to break out chroot and become root on the host.

I think this would be a problem for a shared system (many users, potentially malicious, could login). For most personal laptop / workstation use cases that only one user logs in, I think this should be less of a problem.

I know one of purposes to run "jail"s is to sandbox untrusted code. However, for this specific feature request, I intend to use chroot to just have a separate place for a system -- I'd like to not have a bunch of -dev packages, dev tools, etc. on my host. It's much easier to recreate a chroot than reinstalling my host system if I mess something up inside the chroot. I'm responsible for potentially malicious code inside chroot. If anything could do harm inside chroot, it would do the same anyway if I run it outside. I'm not using chroot as a security sandbox, but rather a separate space for a different setup. I think chroot's the original idea was not for security, but just to test its installation and build system(ref). That is, I don't mind if things inside chroot can break out. I just need the tools to be able to install and run within the chroot.

docker run provides --privileged and --cap-add flags, which IMO is similar to what this feature request. docker can be run with sudo, or by anyone in a docker group (I think this is a popular setup when installing docker).

Why not use chroot or docker instead then? Firejail does a much better job setting up a usable GUI chroot.

But I agree this carries certain security risk, similar to docker's --privileged. I think if guarded by a global option (in /etc/firejail/firejail.config), or checking whether a user has permission to run in this mode (maybe a firejail group, like the docker group for docker), or both, this should be a useful feature for firejail chroot.

@azurvii commented on GitHub (Jun 8, 2023): I found some examples [here](https://benjamintoll.com/2019/05/18/on-escaping-a-chroot/), of using `chdir()` and open file descriptor with root inside chroot, to break out chroot and become root on the host. I think this would be a problem for a shared system (many users, potentially malicious, could login). For most personal laptop / workstation use cases that only one user logs in, I think this should be less of a problem. I know one of purposes to run "jail"s is to sandbox untrusted code. However, for this specific feature request, I intend to use chroot to just have a separate place for a system -- I'd like to not have a bunch of `-dev` packages, dev tools, etc. on my host. It's much easier to recreate a chroot than reinstalling my host system if I mess something up inside the chroot. I'm responsible for potentially malicious code inside chroot. If anything could do harm inside chroot, it would do the same anyway if I run it outside. I'm not using chroot as a security sandbox, but rather a separate space for a different setup. I think `chroot`'s the original idea was not for security, but just `to test its installation and build system`([ref](https://en.wikipedia.org/wiki/Chroot#History)). That is, I don't mind if things inside chroot can break out. I just need the tools to be able to install and run within the chroot. `docker run` provides `--privileged` and `--cap-add` flags, which IMO is similar to what this feature request. `docker` can be run with sudo, or by anyone in a `docker` group (I think this is a popular setup when installing docker). Why not use `chroot` or `docker` instead then? Firejail does a much better job setting up a usable GUI chroot. But I agree this carries certain security risk, similar to `docker`'s `--privileged`. I think if guarded by a global option (in `/etc/firejail/firejail.config`), or checking whether a user has permission to run in this mode (maybe a `firejail` group, like the `docker` group for `docker`), or both, this should be a useful feature for firejail chroot.

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#3103

No description provided.

Rows
Columns

[GH-ISSUE #5827] Allow --caps.keep and newprivs for --chroot #3103

Description

[GH-ISSUE #5827] Allow `--caps.keep` and newprivs for `--chroot` #3103