[GH-ISSUE #3332] firejail container with --chroot? #2090

Closed
opened 2026-05-05 08:45:46 -06:00 by gitea-mirror · 9 comments
Owner

Originally created by @ghost on GitHub (Apr 8, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3332

I'm on a musl system and want to run a glibc binary sandboxed with firejail

the documentation seems vague:

--chroot=dirname
Chroot the sandbox into a root filesystem. Unlike the regular
filesystem container, the system directories are mounted read-
write. If the sandbox is started as a regular user, default
seccomp and capabilities filters are enabled.

Am I still able to utilize the standard profile for the application? Can I still do --private=~/dir/ for a persistent isolated /home/? Can I do --netns?

And why is it read-write? Can I have the rootfs remain read only so that I don't have to remake it for every new application?

On wayland (sway). There is no dbus or puleseaudio (only alsa, and the application is nosound anyway)

Originally created by @ghost on GitHub (Apr 8, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3332 I'm on a musl system and want to run a glibc binary sandboxed with firejail the documentation seems vague: > --chroot=dirname > Chroot the sandbox into a root filesystem. Unlike the regular > filesystem container, the system directories are mounted read- > write. If the sandbox is started as a regular user, default > seccomp and capabilities filters are enabled. Am I still able to utilize the standard profile for the application? Can I still do --private=~/dir/ for a persistent isolated /home/? Can I do --netns? And why is it read-write? Can I have the rootfs remain read only so that I don't have to remake it for every new application? On wayland (sway). There is no dbus or puleseaudio (only alsa, and the application is nosound anyway)
gitea-mirror 2026-05-05 08:45:46 -06:00
Author
Owner

@smitsohu commented on GitHub (Apr 9, 2020):

Am I still able to utilize the standard profile for the application? Can I still do --private=~/dir/ for a persistent isolated /home/? Can I do --netns?

Some of the private options are currently not available in a chroot, but Firejail will complain if you try to use them. All of the net options should work.

And why is it read-write?

Probably it's the way it is because this is a sandbox file system, and modifying it should be relatively safe. You can however use read-only and noexec as usual to rebuild what Firejail does out of the box otherwise. What is your Firejail version?

<!-- gh-comment-id:611423913 --> @smitsohu commented on GitHub (Apr 9, 2020): > Am I still able to utilize the standard profile for the application? Can I still do --private=~/dir/ for a persistent isolated /home/? Can I do --netns? Some of the `private` options are currently not available in a chroot, but Firejail will complain if you try to use them. All of the `net` options should work. > And why is it read-write? Probably it's the way it is because this is a sandbox file system, and modifying it should be relatively safe. You can however use `read-only` and `noexec` as usual to rebuild what Firejail does out of the box otherwise. What is your Firejail version?
Author
Owner

@smitsohu commented on GitHub (Apr 9, 2020):

In order to use --netns, you'll need /etc/netns and /var/run/netns inside the chroot

<!-- gh-comment-id:611426570 --> @smitsohu commented on GitHub (Apr 9, 2020): In order to use `--netns`, you'll need `/etc/netns` and `/var/run/netns ` inside the chroot
Author
Owner

@smitsohu commented on GitHub (Apr 9, 2020):

You can however use read-only and noexec as usual to rebuild what Firejail does out of the box otherwise

read-only /etc
noexec /etc
read-only /var
noexec /var
read-only /usr
read-only /bin
read-only /sbin
read-only /lib
read-only /lib64
read-only /lib32
read-only /libx32
<!-- gh-comment-id:611436845 --> @smitsohu commented on GitHub (Apr 9, 2020): > You can however use `read-only` and `noexec` as usual to rebuild what Firejail does out of the box otherwise ``` read-only /etc noexec /etc read-only /var noexec /var read-only /usr read-only /bin read-only /sbin read-only /lib read-only /lib64 read-only /lib32 read-only /libx32 ```
Author
Owner

@ghost commented on GitHub (Apr 10, 2020):

Perhaps it would be nice to have a feature where firejail would have a more container-like mode and pull files from a specified rootfs rather than /

I had a mind to use something leaner than firejail such as bubblewrap, but it turns out you can't join a network namespace with it which is something I need.

<!-- gh-comment-id:611866584 --> @ghost commented on GitHub (Apr 10, 2020): Perhaps it would be nice to have a feature where firejail would have a more container-like mode and pull files from a specified rootfs rather than / I had a mind to use something leaner than firejail such as bubblewrap, but it turns out you can't join a network namespace with it which is something I need.
Author
Owner

@ghost commented on GitHub (Apr 10, 2020):

Do you know how you would go about pulling a host netns into the chroot? created with the ip netns tool and containing a wireguard interface

<!-- gh-comment-id:611867062 --> @ghost commented on GitHub (Apr 10, 2020): Do you know how you would go about pulling a host netns into the chroot? created with the ip netns tool and containing a wireguard interface
Author
Owner

@smitsohu commented on GitHub (Apr 11, 2020):

Does this work?

sudo mkdir -p [chrootdir]/run/netns
sudo ln -s [chrootdir]/run [chrootdir]/var/run
sudo mount --rbind /var/run/netns [chrootdir]/var/run/netns

As far as I can see it should be possible to then run the sandboxes with
blacklist /var/run/netns.

<!-- gh-comment-id:612426288 --> @smitsohu commented on GitHub (Apr 11, 2020): Does this work? ``` sudo mkdir -p [chrootdir]/run/netns sudo ln -s [chrootdir]/run [chrootdir]/var/run sudo mount --rbind /var/run/netns [chrootdir]/var/run/netns ``` As far as I can see it should be possible to then run the sandboxes with `blacklist /var/run/netns`.
Author
Owner

@ghost commented on GitHub (Apr 14, 2020):

I was not able to make it work.

this however:

sudo ip netns exec vpn1 bwrap --dev-bind / / bash

'ip a' shows it inside the netns

some sudo stuff after exec can make it drop privs.

They made a big deal about the inability of bubblewrap to deal with netns over at their github issues page. Perhaps it was only because they were obsessed about doing it unprivileged.

Is there any problem with using ip netns exec as a hack to get bwrap to work with netns? bwrap comes without a lot of baggage firejail has (I use wayland/sway, and don't use dbus or pulseaudio) and allows to more easily reason about how to get a rootfs to work with all those ro-binds.

<!-- gh-comment-id:613208167 --> @ghost commented on GitHub (Apr 14, 2020): I was not able to make it work. this however: `sudo ip netns exec vpn1 bwrap --dev-bind / / bash` 'ip a' shows it inside the netns some sudo stuff after exec can make it drop privs. They made a big deal about the inability of bubblewrap to deal with netns over at their github issues page. Perhaps it was only because they were obsessed about doing it unprivileged. Is there any problem with using ip netns exec as a hack to get bwrap to work with netns? bwrap comes without a lot of baggage firejail has (I use wayland/sway, and don't use dbus or pulseaudio) and allows to more easily reason about how to get a rootfs to work with all those ro-binds.
Author
Owner

@smitsohu commented on GitHub (Apr 14, 2020):

Good to hear you found a working solution.

Is there any problem with using ip netns exec as a hack to get bwrap to work with netns?

I would guess not. But to be sure I'd recommend to ask on their bug tracker.

<!-- gh-comment-id:613321030 --> @smitsohu commented on GitHub (Apr 14, 2020): Good to hear you found a working solution. > Is there any problem with using ip netns exec as a hack to get bwrap to work with netns? I would guess not. But to be sure I'd recommend to ask on their bug tracker.
Author
Owner

@rusty-snake commented on GitHub (May 6, 2020):

I'm closing here due to inactivity, please fell free to reopen if you have more questions.

<!-- gh-comment-id:624735444 --> @rusty-snake commented on GitHub (May 6, 2020): I'm closing here due to inactivity, please fell free to reopen if you have more questions.
Sign in to join this conversation.
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#2090
No description provided.