github-starred/firejail

Fork 0

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

[GH-ISSUE #566] Per-app security restrictions inside a named Firejail sandbox #402

New issue

Closed

opened 2026-05-05 05:47:25 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 05:47:25 -06:00

Owner

Originally created by @Sidnioulz on GitHub (Jun 11, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/566

So, Firejail is primarily designed to support restricting a specific app, and whatever helpers it spawns. Automatic profile resolution helps us get exactly the folders we need for whatever app we sandbox.

In practice, it may happen that manipulating e.g. a Word or PDF document leads to clicking a link that opens the Web browser. Chrome or Firefox might refuse to run sandboxed, or to run at all, depending on whether the profile launched with that sandbox .

This makes it hard to get reliable results when sandboxing activities/workflows rather than individual apps, as I do on my Firejail + Xfce combo. The issues:

if running without a profile, then every app is a bit less tightly secured than it would have been on its own
some apps won't run because they need to be setuid (e.g. Chromium)
whilst some restrictions could be applied dynamically or to a single process, apps that require special namespace options (e.g. Chromium's inner sandbox sometimes complains about PID namespaces) will be missing those options.

I'd like to use this issue to discuss potential solutions, if that's ok with you.

Possibility 1: using a MAC system with per-binary rules

My initial observation is that namespaces are great at creating alternative domains / realms for apps to run but very poor at enforcing rules that apply to processes / binaries. I feel like isolation could be carried on on a per-process basis much more easily by using AppArmor or SELinux inside the Firejail sandboxes.

Firejail could transform its profile options into rules for a specific SELinux label, and inside any sandbox it creates, just label the binaries of all valid profiles with a unique label. Then, when a new executable is launched within an existing sandbox, SELinux can apply the needed restrictions. Paths that have been manually blacklisted remain so.

For example, evince is set to only read $HOME/.evince. I run "firejail". From my Firejail shell, I have access to all of $HOME. I call evince. SELinux has applied the system_u:firejail__r:evince_t to /usr/bin/evince, and has loaded the appropriate rules to force this evince_t to only see $HOME/.evince.

That would require a bit of exploring and tinkering, and I'm not 100% sure it's possible. The issue with SELinux is that files need to be pre-labelled. The labelling can take time, too. Firejail has an opportunity to solve this issue since labels could be applied to existing files whilst the sandbox is being launched.

Maybe it would only be possible when using a private home or an overlay, to avoid having to deal with the situation of files being created on the host of the sandbox, and therefore not being labelled. Maybe it's only worth labelling hidden files or specific paths like $HOME/.config / .cache / .local to save time, or only paths mentioned in another profile. The paths that were not found when the sandbox was launched can be blacklisted to prevent the "unlabelled new folder" situation described above.

Originally created by @Sidnioulz on GitHub (Jun 11, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/566 So, Firejail is primarily designed to support restricting a specific app, and whatever helpers it spawns. Automatic profile resolution helps us get exactly the folders we need for whatever app we sandbox. In practice, it may happen that manipulating e.g. a Word or PDF document leads to clicking a link that opens the Web browser. Chrome or Firefox might refuse to run sandboxed, or to run at all, depending on whether the profile launched with that sandbox . This makes it hard to get reliable results when sandboxing activities/workflows rather than individual apps, as I do on my Firejail + Xfce combo. The issues: 1. if running without a profile, then every app is a bit less tightly secured than it would have been on its own 2. some apps won't run because they need to be setuid (e.g. Chromium) 3. whilst some restrictions could be applied dynamically or to a single process, apps that require special namespace options (e.g. Chromium's inner sandbox sometimes complains about PID namespaces) will be missing those options. I'd like to use this issue to discuss potential solutions, if that's ok with you. ## Possibility 1: using a MAC system with per-binary rules My initial observation is that namespaces are great at creating alternative domains / realms for apps to run but very poor at enforcing rules that apply to processes / binaries. I feel like isolation could be carried on on a per-process basis much more easily by using AppArmor or SELinux inside the Firejail sandboxes. Firejail could transform its profile options into rules for a specific SELinux label, and inside any sandbox it creates, just label the binaries of all valid profiles with a unique label. Then, when a new executable is launched within an existing sandbox, SELinux can apply the needed restrictions. Paths that have been manually blacklisted remain so. For example, _evince_ is set to only read $HOME/.evince. I run "firejail". From my Firejail shell, I have access to all of $HOME. I call _evince_. SELinux has applied the system_u:firejail_<pid of instance>_r:evince_t to /usr/bin/evince, and has loaded the appropriate rules to force this evince_t to only see $HOME/.evince. That would require a bit of exploring and tinkering, and I'm not 100% sure it's possible. The issue with SELinux is that files need to be pre-labelled. The labelling can take time, too. Firejail has an opportunity to solve this issue since labels could be applied to existing files whilst the sandbox is being launched. Maybe it would only be possible when using a private home or an overlay, to avoid having to deal with the situation of files being created on the host of the sandbox, and therefore not being labelled. Maybe it's only worth labelling hidden files or specific paths like $HOME/.config / .cache / .local to save time, or only paths mentioned in another profile. The paths that were not found when the sandbox was launched can be blacklisted to prevent the "unlabelled new folder" situation described above.

gitea-mirror

2026-05-05 05:47:25 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:47:30 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 12, 2016):

It would be very complicated to develop SELinux or AppArmor profiles for all possible applications. SELinux comes by default with zero profiles for desktop apps, and AppArmor has 3 (evince, firefox and chromium). You need support from SELInux and AppArmor projects to build and maintain a full list of profiles, otherwise you'll end up fixing them every time they release a new version of the software.

@netblue30 commented on GitHub (Jun 12, 2016): It would be very complicated to develop SELinux or AppArmor profiles for all possible applications. SELinux comes by default with zero profiles for desktop apps, and AppArmor has 3 (evince, firefox and chromium). You need support from SELInux and AppArmor projects to build and maintain a full list of profiles, otherwise you'll end up fixing them every time they release a new version of the software.

gitea-mirror commented

2026-05-05 05:47:33 -06:00

Author

Owner

@Sidnioulz commented on GitHub (Jun 12, 2016):

Yup, I agree. In the end the MAC in use could be just a technological means to an end. One course parse a Firejail profile and derive appropriate labels or policies to block/allow the syscalls to different folders according to blacklist commands. The only important bit is that the restrictions apply per binary (the way the binaries would map the profiles).

Restrictions can also be set to limit MIME types in a Firejail profile, again, as above, assuming that complete labelling can be achieved. My suspicion is that it might not be achievable, so it may be better to have a real LSM do that job.

Seccomp wouldn't really be an option, right? Is it easy to reason in it about the path of the current binary being authorised / denied a syscall?

@Sidnioulz commented on GitHub (Jun 12, 2016): Yup, I agree. In the end the MAC in use could be just a technological means to an end. One course parse a Firejail profile and derive appropriate labels or policies to block/allow the syscalls to different folders according to `blacklist` commands. The only important bit is that the restrictions apply per binary (the way the binaries would map the profiles). Restrictions can also be set to limit MIME types in a Firejail profile, again, as above, assuming that complete labelling can be achieved. My suspicion is that it might not be achievable, so it may be better to have a real LSM do that job. Seccomp wouldn't really be an option, right? Is it easy to reason in it about the path of the current binary being authorised / denied a syscall?

gitea-mirror commented

2026-05-05 05:47:36 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 13, 2016):

A seccomp filter is inherited by the all children of a process. You can only add new filters on top of the existing one for each children process started.

@netblue30 commented on GitHub (Jun 13, 2016): A seccomp filter is inherited by the all children of a process. You can only add new filters on top of the existing one for each children process started.

gitea-mirror referenced this issue

2026-05-05 08:08:15 -06:00

[GH-ISSUE #2200] --read-only recursiveness does not cross filesystem boundaries #1471

gitea-mirror referenced this issue

2026-05-05 08:08:21 -06:00

[GH-ISSUE #2200] --read-only recursiveness does not cross filesystem boundaries #1471

gitea-mirror referenced this issue

2026-05-05 08:25:13 -06:00

[GH-ISSUE #2792] Wiki: Frequently Asked Questions #1747