github-starred/firejail

Fork 0

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

[GH-ISSUE #463] Is "--noroot" implicitly at odds with "--chroot"? #329

New issue

Closed

opened 2026-05-05 05:36:41 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 05:36:41 -06:00

Owner

Originally created by @ptoomey3 on GitHub (Apr 20, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/463

I noticed that the docs state that --noroot can't be used when using --chroot. I am curious if there is something foundational that would prevent this from being implemented in the future? Using --chroot is nice in that is minimizes the amount of blacklisting/whitelisting that is necessary. But, it would be nice to prevent escalation to root inside the chroot as well.

Originally created by @ptoomey3 on GitHub (Apr 20, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/463 I noticed that the docs state that `--noroot` can't be used when using `--chroot`. I am curious if there is something foundational that would prevent this from being implemented in the future? Using `--chroot` is nice in that is minimizes the amount of blacklisting/whitelisting that is necessary. But, it would be nice to prevent escalation to root inside the chroot as well.

gitea-mirror

2026-05-05 05:36:41 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:36:46 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 21, 2016):

I have to revisit this, a long time ago when --noroot was implemented there were some problems on chroots. I'll take a look, thanks.

@netblue30 commented on GitHub (Apr 21, 2016): I have to revisit this, a long time ago when --noroot was implemented there were some problems on chroots. I'll take a look, thanks.

gitea-mirror commented

2026-05-05 05:36:48 -06:00

Author

Owner

@ptoomey3 commented on GitHub (Apr 22, 2016):

If it is still roughly the same code I sent you last year, I'm probably to blame 😄. I had never even tested that code with a chroot. Thanks for taking a look!

@ptoomey3 commented on GitHub (Apr 22, 2016): If it is still roughly the same code I sent you last year, I'm probably to blame :smile:. I had never even tested that code with a chroot. Thanks for taking a look!

gitea-mirror commented

2026-05-05 05:36:49 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 23, 2016):

I've found it! We have something like this:

$ cat t.c
#include <stdio.h>
#include <unistd.h>
#include <linux/sched.h>
int main() {
    chroot("/tmp/chroot");
    perror("chroot");
    unshare(CLONE_NEWUSER);
    perror("unshare");
    return 0;
}
$ sudo ./a.out
chroot: Success
unshare: Operation not permitted
$

unshare fails inside a chroot, and this is what they say in man 2 unshare:

       EPERM (since Linux 3.9)
              CLONE_NEWUSER was specified in flags and  the  caller  is  in  a
              chroot  environment  (i.e., the caller's root directory does not
              match the root directory of the  mount  namespace  in  which  it
              resides).

My guess is somebody figured out a way to escape chroot using a user namespace, and they disabled it in the kernel.

@netblue30 commented on GitHub (Apr 23, 2016): I've found it! We have something like this: ``` $ cat t.c #include <stdio.h> #include <unistd.h> #include <linux/sched.h> int main() { chroot("/tmp/chroot"); perror("chroot"); unshare(CLONE_NEWUSER); perror("unshare"); return 0; } $ sudo ./a.out chroot: Success unshare: Operation not permitted $ ``` unshare fails inside a chroot, and this is what they say in man 2 unshare: ``` EPERM (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides). ``` My guess is somebody figured out a way to escape chroot using a user namespace, and they disabled it in the kernel.

gitea-mirror commented

2026-05-05 05:36:50 -06:00

Author

Owner

@ptoomey3 commented on GitHub (Apr 23, 2016):

Maybe this: https://lwn.net/Articles/543273/. It seems there is some shared state with the parent process when you call chroot that would be at odds with running in a separate user namespace. So, I guess they just disabled it all together.

@ptoomey3 commented on GitHub (Apr 23, 2016): Maybe this: https://lwn.net/Articles/543273/. It seems there is some shared state with the parent process when you call `chroot` that would be at odds with running in a separate user namespace. So, I guess they just disabled it all together.

gitea-mirror commented

2026-05-05 05:36:51 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 24, 2016):

We'll keep an eye on it, maybe they change their mind a put a better fix in.

@netblue30 commented on GitHub (Apr 24, 2016): We'll keep an eye on it, maybe they change their mind a put a better fix in.

gitea-mirror commented

2026-05-05 05:36:52 -06:00

Author

Owner

@ptoomey3 commented on GitHub (May 2, 2016):

😿 - But I understand it isn't in your control.

@ptoomey3 commented on GitHub (May 2, 2016): 😿 - But I understand it isn't in your control.

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

No description provided.

Rows
Columns