--no-join (option to disallow firejail --join)

[testbird]

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 ?

[netblue30]

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?

[testbird]

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]

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).

[netblue30]

I meant iptables on the host or the router.

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

[testbird]

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

[netblue30]

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.

[testbird]

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?

[netblue30]

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

[chiraag-nataraj]

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

[Vincent43]

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.

[chiraag-nataraj]

Hmm, that's true @Vincent43...

[testbird]

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?

[Vincent43]

@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.

[testbird]

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.

[Vincent43]

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.

[testbird]

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

[Vincent43]

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.

[chiraag-nataraj]

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).

[testbird]

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).