[GH-ISSUE #1117] --no-join (option to disallow firejail --join)

gitea-mirror commented

2026-05-05 06:36:55 -06:00

Owner

Originally created by @testbird on GitHub (Feb 28, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1117

For example, if networking tools (like khtml, wget, python, or even firefox) are run in a sandbox in order to only allow a limited set of tools access to the network (all other traffic blocked, only the sandbox with specific mac/ip has some allow rules), it is also important to prevent other applications from accessing the network by using --join and accessing the net thought the sandboxed tool.
--no-join ?

Starting a sandbox with an already reserved/existing mac/ip would also have to be blocked.
Specific mac/ip configured in a profile? and
--unique-net ?

Originally created by @testbird on GitHub (Feb 28, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1117 For example, if networking tools (like khtml, wget, python, or even firefox) are run in a sandbox in order to only allow a limited set of tools access to the network (all other traffic blocked, only the sandbox with specific mac/ip has some allow rules), it is also important to prevent other applications from accessing the network by using --join and accessing the net thought the sandboxed tool. --no-join ? Starting a sandbox with an already reserved/existing mac/ip would also have to be blocked. Specific mac/ip configured in a profile? and --unique-net ?

gitea-mirror added the

enhancement

label 2026-05-05 06:36:55 -06:00

gitea-mirror commented

2026-05-05 06:37:00 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 28, 2017):

I'll add --no-join. You'll be able to start a non-joinable sandbox.

The current code does an arp request before assigning the ip address. It will check if the address is in use. You can also specify a range of addresses for the new sandbox (--iprange). The mac address is assigned randomly by the kernel, unless it was specified by the user. Will this work?

@netblue30 commented on GitHub (Feb 28, 2017): I'll add --no-join. You'll be able to start a non-joinable sandbox. The current code does an arp request before assigning the ip address. It will check if the address is in use. You can also specify a range of addresses for the new sandbox (--iprange). The mac address is assigned randomly by the kernel, unless it was specified by the user. Will this work?

gitea-mirror commented

2026-05-05 06:37:02 -06:00

Author

Owner

@testbird commented on GitHub (Feb 28, 2017):

Thanks for explaining. I've tested creating a sandbox with an already existing mac address on the same machine and it also seems to fail properly: ioctl: network.c:217 net_if_up: Device or resource busy.

But the sandbox that is allowed to have network access may not always be running (and thus blocking the use of the addresses). This means blocking all network traffic for the host does not prevent anybody from gaining network access. Anyone/thing could start a firejail with the allowed network adresses.

I think my first idea, to have some configuration to reserve specific addresses for some profiles "unique or reserved-net" (so they can not be used with other configurations) may have been flawed.

Could it be a more general problem of the suid handling of firejail, that it effectively allows regular users to create new nodes on the network? May it be wise to only allow (non-local) --net configurations for root (or all users with preexisting permissions) and in root owned profiles? (Kind of executing part of firejail setup code under NO_NEW_PRIVS, exept when configured by root owned profiles?)

@testbird commented on GitHub (Feb 28, 2017): Thanks for explaining. I've tested creating a sandbox with an already existing mac address on the same machine and it also seems to fail properly: ioctl: network.c:217 net_if_up: Device or resource busy. But the sandbox that is allowed to have network access may not always be running (and thus blocking the use of the addresses). This means blocking all network traffic for the host does not prevent anybody from gaining network access. Anyone/thing could start a firejail with the allowed network adresses. I think my first idea, to have some configuration to reserve specific addresses for some profiles "unique or reserved-net" (so they can not be used with other configurations) may have been flawed. Could it be a more general problem of the suid handling of firejail, that it effectively allows regular users to create new nodes on the network? May it be wise to only allow (non-local) --net configurations for root (or all users with preexisting permissions) and in root owned profiles? (Kind of executing part of firejail setup code under NO_NEW_PRIVS, exept when configured by root owned profiles?)

gitea-mirror commented

2026-05-05 06:37:05 -06:00

Author

Owner

@testbird commented on GitHub (Feb 28, 2017):

It may not have been clear, when I wrote network access is blocked, I meant iptables on the host or the router. Which unprivileged users may circumvent by having firejail bring up an interface (with the address equal to a special profile that sets a single application up in a limited sandbox with an address that has network access granted).

@testbird commented on GitHub (Feb 28, 2017): It may not have been clear, when I wrote network access is blocked, I meant iptables on the host or the router. Which unprivileged users may circumvent by having firejail bring up an interface (with the address equal to a special profile that sets a single application up in a limited sandbox with an address that has network access granted).

gitea-mirror commented

2026-05-05 06:37:08 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 3, 2017):

I meant iptables on the host or the router.

There is no integration with the main netfilter setup running on the box.

@netblue30 commented on GitHub (Mar 3, 2017): > I meant iptables on the host or the router. There is no integration with the main netfilter setup running on the box.

gitea-mirror commented

2026-05-05 06:37:10 -06:00

Author

Owner

@testbird commented on GitHub (Mar 5, 2017):

removed "dissallowing clone operations" from this issue (now #1123)

@testbird commented on GitHub (Mar 5, 2017): removed "dissallowing clone operations" from this issue (now #1123)

gitea-mirror commented

2026-05-05 06:37:12 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 23, 2017):

Ended up with a different implementation based on "join" flag in /etc/firejail/firejail.config.

If "join yes" (default), the user can join the sandbox. If "join no" the user cannot join the sandbox. Superuser (root) can always join a sandbox - he can do it anyway using a variety of other tools.

The way to use it is to keep "join no" configured, and switch it to "join yes" when you really need to join a sandbox, only to put it back to "no" when you are done.

@netblue30 commented on GitHub (Mar 23, 2017): Ended up with a different implementation based on "join" flag in /etc/firejail/firejail.config. If "join yes" (default), the user can join the sandbox. If "join no" the user cannot join the sandbox. Superuser (root) can always join a sandbox - he can do it anyway using a variety of other tools. The way to use it is to keep "join no" configured, and switch it to "join yes" when you really need to join a sandbox, only to put it back to "no" when you are done.

gitea-mirror commented

2026-05-05 06:37:13 -06:00

Author

Owner

@testbird commented on GitHub (Mar 27, 2017):

The way to use it is to keep "join no" configured, and switch it to "join yes" when you really need to join a sandbox, only to put it back to "no" when you are done.

IIUC this firejail.config setting will allow it globally for all profiles. Was it not possible to make this a per profile setting in the profile files configured by root under /etc? Or doesn't this make sense?

@testbird commented on GitHub (Mar 27, 2017): > The way to use it is to keep "join no" configured, and switch it to "join yes" when you really need to join a sandbox, only to put it back to "no" when you are done. IIUC this firejail.config setting will allow it globally for all profiles. Was it not possible to make this a per profile setting in the profile files configured by root under /etc? Or doesn't this make sense?

gitea-mirror commented

2026-05-05 06:37:14 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 28, 2017):

Let me reopen it, maybe we can bring it in.

@netblue30 commented on GitHub (Mar 28, 2017): Let me reopen it, maybe we can bring it in.

gitea-mirror commented

2026-05-05 06:37:16 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 19, 2019):

Hey @netblue30, just wondering if we still intend to make this a per-profile switch?

@chiraag-nataraj commented on GitHub (May 19, 2019): Hey @netblue30, just wondering if we still intend to make this a per-profile switch?

gitea-mirror commented

2026-05-05 06:37:17 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 20, 2019):

What is the usecase for profile switch? You could join only through firejail but if you have access to firejail then you may pass firejail --ignore nojoin <profile> bypassing the restriction.

@Vincent43 commented on GitHub (May 20, 2019): What is the usecase for profile switch? You could join only through firejail but if you have access to firejail then you may pass `firejail --ignore nojoin <profile>` bypassing the restriction.

gitea-mirror commented

2026-05-05 06:37:20 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 20, 2019):

Hmm, that's true @Vincent43...

@chiraag-nataraj commented on GitHub (May 20, 2019): Hmm, that's true @Vincent43...

gitea-mirror commented

2026-05-05 06:37:21 -06:00

Author

Owner

@testbird commented on GitHub (May 22, 2019):

https://github.com/netblue30/firejail/issues/1117#issuecomment-289446469

Not sure right now anymore.
For user root to globally disallow --join, while allowing some users to use e.g. an email app, but not use the network access of that profile with another binary?

@testbird commented on GitHub (May 22, 2019): https://github.com/netblue30/firejail/issues/1117#issuecomment-289446469 Not sure right now anymore. For user root to globally disallow --join, while allowing some users to use e.g. an email app, but not use the network access of that profile with another binary?

gitea-mirror commented

2026-05-05 06:37:23 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 22, 2019):

@testbird As I wrote per-profile switch is ineffective if you want to prevent user from joining to any app of their choice. Only disabling it globally makes sense.

@Vincent43 commented on GitHub (May 22, 2019): @testbird As I wrote per-profile switch is ineffective if you want to prevent user from joining to any app of their choice. Only disabling it globally makes sense.

gitea-mirror commented

2026-05-05 06:37:24 -06:00

Author

Owner

@testbird commented on GitHub (May 29, 2019):

I see, if I understand you maybe only a per-profile allow-join could make sence then, to allow some user access as an exception?

Maybe not yet.

Because I think what what irritates me may be more basic, i.e. that firejail does not seem to "drop priviledges" to the level of the executing user, at least where it makes sence, like preventing unprivileged users from overriding central, root-owned, read-only profile definition settings.

@testbird commented on GitHub (May 29, 2019): I see, if I understand you maybe only a per-profile allow-join could make sence then, to allow some user access as an exception? Maybe not yet. Because I think what what irritates me may be more basic, i.e. that firejail does not seem to "drop priviledges" to the level of the executing user, at least where it makes sence, like preventing unprivileged users from overriding central, root-owned, read-only profile definition settings.

gitea-mirror commented

2026-05-05 06:37:27 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 29, 2019):

In general firejail doesn't protect against malicious local users. It protects users from the apps not apps from the users. Note that anyone can easily bypass firejail by starting app with full path like /usr/bin/firefox so preventing users from modifying profiles doesn't make sense. Containing users may be possible by changing their login shell to /usr/bin/firejail but such environment would be very limited and hard to make useful.

@Vincent43 commented on GitHub (May 29, 2019): In general firejail doesn't protect against malicious local users. It protects users from the apps not apps from the users. Note that anyone can easily bypass firejail by starting app with full path like `/usr/bin/firefox` so preventing users from modifying profiles doesn't make sense. Containing users may be possible by changing their login shell to `/usr/bin/firejail` but such environment would be very limited and hard to make useful.

gitea-mirror commented

2026-05-05 06:37:28 -06:00

Author

Owner

@testbird commented on GitHub (May 29, 2019):

But can't compromised apps (running with a local user account) not execute firejail just as the local user itself?

@testbird commented on GitHub (May 29, 2019): But can't compromised apps (running with a local user account) not execute firejail just as the local user itself?

gitea-mirror commented

2026-05-05 06:37:30 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 29, 2019):

When run in firejail sandbox, compromised apps have much less privileges than local user outside sandbox and they can't use firejail to modify it (even to make it more strict). What exactly they can do is defined by a profile + command args and they're controlled by user (and firejail) not an app.

@Vincent43 commented on GitHub (May 29, 2019): When run in firejail sandbox, compromised apps have much less privileges than local user outside sandbox and they can't use firejail to modify it (even to make it more strict). What exactly they can do is defined by a profile + command args and they're controlled by user (and firejail) not an app.

gitea-mirror commented

2026-05-05 06:37:31 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 29, 2019):

Because I think what what irritates me may be more basic, i.e. that firejail does not seem to "drop priviledges" to the level of the executing user, at least where it makes sence, like preventing unprivileged users from overriding central, root-owned, read-only profile definition settings.

Except, like, firejail "goes to sleep" after launching the child process (the program you wanted to start).

The entire security model (and the threat firejail is meant to protect against) is the case where the program is behaving maliciously. That is, say there's a drive-by download in firefox and the program is supposed to run automatically after downloading. Well, within the context of firejail, the potential for damage (and the files the malicious program can reach) is far less than if firefox isn't run through firejail.

firejail is not a MAC (Mandatory Access Control) system. It is a sandbox meant to contain programs, not users (although gross-level control can be achieved by setting firejail as the login shell as @Vincent43 mentioned).

As for overriding centrally-defined settings, there are some settings you can set within firejail.config in this regard (e.g. disable-mnt). But in general, firejail is meant for the case of the single-user desktop system, where the biggest concern is malicious programs rather than malicious users.

If you want a system designed to contain users, you should think about using tools like SELinux, SMACK, Tomoyo, AppArmor, etc. Those are MAC systems designed to constrain what users can do (and, as a result, also can constrain what programs can do).

@chiraag-nataraj commented on GitHub (May 29, 2019): > Because I think what what irritates me may be more basic, i.e. that firejail does not seem to "drop priviledges" to the level of the executing user, at least where it makes sence, like preventing unprivileged users from overriding central, root-owned, read-only profile definition settings. Except, like, `firejail` "goes to sleep" after launching the child process (the program you wanted to start). The entire security model (and the threat `firejail` is meant to protect against) is the case where the program is behaving maliciously. That is, say there's a drive-by download in `firefox` and the program is supposed to run automatically after downloading. Well, within the context of `firejail`, the potential for damage (and the files the malicious program can reach) is far less than if `firefox` _isn't_ run through `firejail`. `firejail` is not a MAC (Mandatory Access Control) system. It is a sandbox meant to contain _programs_, not users (although gross-level control can be achieved by setting `firejail` as the login shell as @Vincent43 mentioned). As for overriding centrally-defined settings, there are _some_ settings you can set within `firejail.config` in this regard (e.g. `disable-mnt`). But in general, `firejail` is meant for the case of the single-user desktop system, where the biggest concern is malicious programs rather than malicious users. If you want a system designed to contain users, you should think about using tools like SELinux, SMACK, Tomoyo, AppArmor, etc. Those are MAC systems designed to constrain what users can do (and, as a result, _also_ can constrain what programs can do).

gitea-mirror commented

2026-05-05 06:37:32 -06:00

Author

Owner

@testbird commented on GitHub (May 29, 2019):

Thank you for your explanations. So the idea here may only have been wrongly inspired from that firejail option for apparmor support (a different thing).

The envisioned example use case here was restricting nework access, simply by blocking all network traffic (iptables) on a system by default (changing this requires root) and only allow running "sudo firejail firefox" in the sudoes config to allow some users browsing the internet under a separate user account with a profile that has network traffic allowed (separate user's socket and even IP).

@testbird commented on GitHub (May 29, 2019): Thank you for your explanations. So the idea here may only have been wrongly inspired from that firejail option for apparmor support (a different thing). The envisioned example use case here was restricting nework access, simply by blocking all network traffic (iptables) on a system by default (changing this requires root) and only allow running "sudo firejail firefox" in the sudoes config to allow some users browsing the internet under a separate user account with a profile that has network traffic allowed (separate user's socket and even IP).

Rows
Columns

[GH-ISSUE #1117] --no-join (option to disallow firejail --join) #768