[GH-ISSUE #290] firejail allows regular users to assign arbitrary address (IP, MAC) on any network interface

gitea-mirror commented

2026-05-05 05:18:33 -06:00

Owner

Originally created by @yumkam on GitHub (Feb 11, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/290

...and also disrespects any policy set by DHCP/etc.
(Obviously, it is only possible because firejail is setuid root, it is not possibly to do from within unprivileged userns (unshare -r -n) [unless "real root" will give them "real" netdev to play, with something like ip link set $XXX netns $YYY]).
(Sure, anyone with physical access to network can do the same, but still it requires intent, knowledge and can be noticed; but any little-educated user can run firejail --net=eth0 and wreak havoc on LAN).
IMO, there should be (root-only writable) policy file, that restrict set of allowed interfaces, MAC and IP pools. By default, it should allow only --net=none; others are nice toy to play with [and I love them], but a way too powerful for regular users.
(There can be other ideas, as allow/enforce running some dhclient, but it's too complex, let's leave it for later).
Otherwise, IMO, firejail is unsafe to install as suid-root (unless it is built with --disable-network, or restricted to "power-user"/sudo group, etc).

Originally created by @yumkam on GitHub (Feb 11, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/290 ...and also disrespects any policy set by DHCP/etc. (Obviously, it is only possible because firejail is setuid root, it is not possibly to do from within unprivileged userns (`unshare -r -n`) [unless "real root" will give them "real" netdev to play, with something like `ip link set $XXX netns $YYY`]). (Sure, anyone with physical access to network can do the same, but still it requires intent, knowledge and can be noticed; but any little-educated user can run `firejail --net=eth0` and wreak havoc on LAN). IMO, there should be (root-only writable) policy file, that restrict set of allowed interfaces, MAC and IP pools. By default, it should allow only `--net=none`; others are nice toy to play with [and I love them], but a way too powerful for regular users. (There can be other ideas, as allow/enforce running some dhclient, but it's too complex, let's leave it for later). Otherwise, IMO, firejail is unsafe to install as suid-root (unless it is built with --disable-network, or restricted to "power-user"/`sudo` group, etc).

gitea-mirror

2026-05-05 05:18:33 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:18:39 -06:00

Author

Owner

@genodeftest commented on GitHub (Feb 11, 2016):

Wouldn't it be easier to drop the setuid bit? Linux namespaces doesn't require this stuff anyway.

@genodeftest commented on GitHub (Feb 11, 2016): Wouldn't it be easier to drop the `setuid` bit? Linux namespaces doesn't require this stuff anyway.

gitea-mirror commented

2026-05-05 05:18:42 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 11, 2016):

It is not a security issue. It allows the user to set IP addresses on new interfaces created in a new network namespace inside the sandbox. Interfaces in the main network namespace are not affected.

@netblue30 commented on GitHub (Feb 11, 2016): It is not a security issue. It allows the user to set IP addresses on new interfaces created in a new network namespace inside the sandbox. Interfaces in the main network namespace are not affected.

gitea-mirror commented

2026-05-05 05:18:44 -06:00

Author

Owner

@yumkam commented on GitHub (Feb 11, 2016):

@netblue30:
(nitpicking) Intefraces in main namespaces are affected: they are switched to promiscuous mode (with some network cards).
(Not nitpicking) It affects LAN security and breaks (some) local network policy. It is not possible to add new devices with new random MAC/IP addresses with user rights, it is possible with firejail.
Real problem: I have another machine on LAN, it has fixed (by dhcp) address. If I ran application in firejail while that machine is off, it happily hijacks address, and results in problems when this machine is turned on.
Real problem: some ISP forbids devices with unknown MACs on their network (and, of course, attempt to hijack someone's else IP address will be frowned upon).

@yumkam commented on GitHub (Feb 11, 2016): @netblue30: (nitpicking) Intefraces in main namespaces are affected: they are switched to promiscuous mode (with some network cards). (Not nitpicking) It affects LAN security and breaks (some) local network policy. It is not possible to add new devices with new random MAC/IP addresses with user rights, it is possible with firejail. Real problem: I have another machine on LAN, it has fixed (by dhcp) address. If I ran application in firejail while that machine is off, it happily hijacks address, and results in problems when this machine is turned on. Real problem: some ISP forbids devices with unknown MACs on their network (and, of course, attempt to hijack someone's else IP address will be frowned upon).

gitea-mirror commented

2026-05-05 05:18:46 -06:00

Author

Owner

@yumkam commented on GitHub (Feb 11, 2016):

@genodeftest: it is possible to do some tricks with unprivileged userns, but it will require constantly playing with permissions/dancing with chowning files to subuid and back/etc (or you'll even need full-blown chroot) and it will lack convenience firejail currently provides (you just add firejail in front and everything works as usual). So, unfortunately, if you want to keep user-friendliness, suid root on firejail binary is required. But in some cases (as with networking stuff), firejail delegates a way too much power to user, and this should be restricted. IMO.

@yumkam commented on GitHub (Feb 11, 2016): @genodeftest: it is possible to do some tricks with unprivileged userns, but it will require constantly playing with permissions/dancing with `chown`ing files to subuid and back/etc (or you'll even need full-blown chroot) and it will lack convenience firejail currently provides (you just add `firejail` in front and everything works as usual). So, unfortunately, if you want to keep user-friendliness, suid root on firejail binary is required. But in some cases (as with networking stuff), firejail delegates a way too much power to user, and this should be restricted. IMO.

gitea-mirror commented

2026-05-05 05:18:47 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 11, 2016):

@yumkam

Interfaces in main namespaces are affected: they are switched to promiscuous mode (with some network cards)

This is a limitation of the current Linux kernel code, I'm sure it was not intended to be that way.

DHCP

Currently, support for DHCP is not implemented. I intend to add it in a future release. In this moment you have full control over IP/MAC addresses. You can also specify ranges of IP addresses assigned by the sandbox:

$ firejail --net=eth0 --iprange=192.168.1.100,192.168.1.150

firejail delegates a way too much power to user, and this should be restricted

I totally agree with you, but the current setup works fine in most of the cases - at least for home users or server farms. One place I've found this kind of networking support should not be allowed is servers where people log in remotely, and you cannot allow them to bring in new nodes on the network. Also user namespace seems to be a problem with some users.

You can disable some of the most questionable features at compile time, including networking support:

$ ./configure --help
[...]
Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-seccomp       disable seccomp
  --disable-chroot        disable chroot
  --disable-bind          disable bind
  --disable-network       disable network
  --disable-userns        disable user namespace
  --enable-fatal-warnings -W -Wall -Werror
[...]

@netblue30 commented on GitHub (Feb 11, 2016): @yumkam > Interfaces in main namespaces are affected: they are switched to promiscuous mode (with some network cards) This is a limitation of the current Linux kernel code, I'm sure it was not intended to be that way. > DHCP Currently, support for DHCP is not implemented. I intend to add it in a future release. In this moment you have full control over IP/MAC addresses. You can also specify ranges of IP addresses assigned by the sandbox: ``` $ firejail --net=eth0 --iprange=192.168.1.100,192.168.1.150 ``` > firejail delegates a way too much power to user, and this should be restricted I totally agree with you, but the current setup works fine in most of the cases - at least for home users or server farms. One place I've found this kind of networking support should not be allowed is servers where people log in remotely, and you cannot allow them to bring in new nodes on the network. Also user namespace seems to be a problem with some users. You can disable some of the most questionable features at compile time, including networking support: ``` $ ./configure --help [...] Optional Features: --disable-option-checking ignore unrecognized --enable/--with options --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --disable-seccomp disable seccomp --disable-chroot disable chroot --disable-bind disable bind --disable-network disable network --disable-userns disable user namespace --enable-fatal-warnings -W -Wall -Werror [...] ```

gitea-mirror commented

2026-05-05 05:18:48 -06:00

Author

Owner

@the8472 commented on GitHub (Feb 11, 2016):

@yumkam

It is not possible to add new devices with new random MAC/IP addresses with user rights, it is possible with firejail.

Don't container solutions such as docker have similar capabilities? Afaik they can utilize a bridge interface in a similar fashion as firejail does.

@the8472 commented on GitHub (Feb 11, 2016): @yumkam > It is not possible to add new devices with new random MAC/IP addresses with user rights, it is possible with firejail. Don't container solutions such as docker have similar capabilities? Afaik they can utilize a bridge interface in a similar fashion as firejail does.

gitea-mirror commented

2026-05-05 05:18:50 -06:00

Author

Owner

@yumkam commented on GitHub (Feb 11, 2016):

@netblue30:

This is a limitation of the current Linux kernel code, I'm sure it was not intended to be that way.

This is hardware limitation (some cards lacks unicast fitering, so either you are promiscuous, or macvlan/bridge won't work; ipvlan maybe will work without PROMISC, but my kernel predates it [anyway, ipvlan has same problem with arbitrary-assigned IP]).

You can disable some of the most questionable features at compile time

Not if you use distribution-built package.

P.S. one more problem, it also completely bypasses (more like, ignores) system-wide firewall and routing settings. It maybe not very important in many simple/typical single-user configuration, but in some cases this is unacceptable (and sometimes even costly or dangerous); imagine some kind of “parental control” that restricts access by user/group with iptables; start firejail --eth0 — and you are out of jail; or imagine transparent torifying for certain uids/gids; run safely in globally-torified environment, run firejail --net=eth0 firefox for additional safety — oops, you landed in jail [the real one].

@the8472: (on docker/etc)
Are they setuid root too? You cannot make macvlan or bridged veth and attach them to netns without "outer" root rights. If you have "root" rights only in unprivileged userns (unshare -rn), you can only have equivalent of firejail --net=none (which is safe, AFAIK).

@yumkam commented on GitHub (Feb 11, 2016): @netblue30: > This is a limitation of the current Linux kernel code, I'm sure it was not intended to be that way. This is **hardware** limitation (some cards lacks unicast fitering, so either you are promiscuous, or macvlan/bridge won't work; ipvlan maybe will work without PROMISC, but my kernel predates it [anyway, ipvlan has same problem with arbitrary-assigned IP]). > You can disable some of the most questionable features at compile time Not if you use distribution-built package. P.S. one more problem, it also completely bypasses (more like, ignores) system-wide firewall and routing settings. It maybe not very important in many simple/typical single-user configuration, but in some cases this is unacceptable (and sometimes even costly or dangerous); imagine some kind of “parental control” that restricts access by user/group with iptables; start `firejail --eth0` — and you are out of jail; or imagine transparent torifying for certain uids/gids; run safely in globally-torified environment, run `firejail --net=eth0 firefox` for additional safety — oops, you landed in jail [the **real** one]. @the8472: (on docker/etc) Are they setuid root too? You cannot make macvlan or bridged veth and attach them to netns without "outer" root rights. If you have "root" rights only in unprivileged userns (`unshare -rn`), you can only have equivalent of `firejail --net=none` (which is safe, AFAIK).

gitea-mirror commented

2026-05-05 05:18:51 -06:00

Author

Owner

@the8472 commented on GitHub (Feb 11, 2016):

@yumkam, well, instead of setuid docker uses a daemon running as root and non-privileged users talk to it via sockets. But yeah, effectively it does similar things.

I think a relatively simple solution would be for firejail to check some kind of root-owned policy file that contains a list of users that are allowed to use certain features.

It would then be up to the distros which policy file they ship by default.

@the8472 commented on GitHub (Feb 11, 2016): @yumkam, well, instead of setuid docker uses a daemon running as root and non-privileged users talk to it via sockets. But yeah, effectively it does similar things. I think a relatively simple solution would be for firejail to check some kind of root-owned policy file that contains a list of users that are allowed to use certain features. It would then be up to the distros which policy file they ship by default.

gitea-mirror commented

2026-05-05 05:18:52 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 11, 2016):

Docker runs as root, so is not a problem.

You can run LXC as regular user with user namespace enabled, but the program calls an external SUID binary to set IP addresses - basically you end up in the same situation as firejail.

I understand the hardware limitation, there is nothing I can do about it in user space. If you use macvlan devices you might end up with your Ethernet card in promiscuous mode. It affects all the software running on Linux.

P.S. one more problem, it also completely bypasses (more like, ignores) system-wide firewall and routing settings. It maybe not very important in many simple/typical single-user configuration, but in some cases this is unacceptable

Don't compile the network support in! Typical single-user/desktop configuration is my main target. For all desktop programs, I install a default firewall in the network namespace. The firewall is configurable. There is no support for importing the route table in the network namespace, maybe I should add it in. Parent control is way beyond the scope of this project.

As for tor, there were some attempts to build a security profile, so far I let the user build his own. There are all kind of issues there, maybe the best solution would be to proxy everything as suggested in https://github.com/netblue30/firejail/issues/108 . I'm not sure how this will go.

@netblue30 commented on GitHub (Feb 11, 2016): Docker runs as root, so is not a problem. You can run LXC as regular user with user namespace enabled, but the program calls an external SUID binary to set IP addresses - basically you end up in the same situation as firejail. I understand the hardware limitation, there is nothing I can do about it in user space. If you use macvlan devices you might end up with your Ethernet card in promiscuous mode. It affects all the software running on Linux. > P.S. one more problem, it also completely bypasses (more like, ignores) system-wide firewall and routing settings. It maybe not very important in many simple/typical single-user configuration, but in some cases this is unacceptable Don't compile the network support in! Typical single-user/desktop configuration is my main target. For all desktop programs, I install a default firewall in the network namespace. The firewall is configurable. There is no support for importing the route table in the network namespace, maybe I should add it in. Parent control is way beyond the scope of this project. As for tor, there were some attempts to build a security profile, so far I let the user build his own. There are all kind of issues there, maybe the best solution would be to proxy everything as suggested in https://github.com/netblue30/firejail/issues/108 . I'm not sure how this will go.

gitea-mirror commented

2026-05-05 05:18:53 -06:00

Author

Owner

@h1z1 commented on GitHub (Feb 13, 2016):

This thread is quite scary. The reason I avoided docker for firejail was their flawed security model. I cannot fathom how allowing users to configure anything in a jail they would not be permitted to do outside, is acceptable?? Unless I'm misunderstanding the intention, Firejail should be as static as possible, it's not meant to replace a full VM. If a daemon inside a jail is compromised, it should be restricted as much as possible. Interactive users logging in from remote is moot.

I didn't' realize firejail even installed as setuid. Without a proper security audit that seems like a disaster waiting to happen.

@h1z1 commented on GitHub (Feb 13, 2016): This thread is quite scary. The reason I avoided docker for firejail was their flawed security model. I cannot fathom how allowing users to configure anything in a jail they would not be permitted to do outside, is acceptable?? Unless I'm misunderstanding the intention, Firejail should be as static as possible, it's not meant to replace a full VM. If a daemon inside a jail is compromised, it should be restricted as much as possible. Interactive users logging in from remote is moot. I didn't' realize firejail even installed as setuid. Without a proper security audit that seems like a disaster waiting to happen.

gitea-mirror commented

2026-05-05 05:18:54 -06:00

Author

Owner

@the8472 commented on GitHub (Feb 13, 2016):

Think of it as a separate device in your network. That shields the host system and any process that only listens on localhost on the host from contents of the jailed system.

Additionally you can define netfilter rules (e.g. nolocal.net) to permit internet access but prevent lan-local access. This way it provides far more isolation than it would if it shared the network namespace with the host.

I didn't' realize firejail even installed as setuid.

It's right there in the manpage:

DESCRIPTION
Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications
using Linux namespaces, seccomp-bpf and Linux capabilities.

@the8472 commented on GitHub (Feb 13, 2016): Think of it as a separate device in your network. That shields the host system and any process that only listens on localhost on the host from contents of the jailed system. Additionally you can define netfilter rules (e.g. `nolocal.net`) to permit internet access but prevent lan-local access. This way it provides far more isolation than it would if it shared the network namespace with the host. > I didn't' realize firejail even installed as setuid. It's right there in the manpage: > DESCRIPTION > **Firejail is a SUID sandbox program** that reduces the risk of security breaches by restricting the running environment of untrusted applications > using Linux namespaces, seccomp-bpf and Linux capabilities.

gitea-mirror commented

2026-05-05 05:18:55 -06:00

Author

Owner

@h1z1 commented on GitHub (Feb 13, 2016):

Understood, I do think of it as a shield, that is the problem. Indeed it is in the man page too. That doesn't negate that I didn't know however. By doing so you've essentially taken the systemd approach - bypass any OS protections because we know better. That is a bit troubling. I would personally prefer forcing root to setup jails or use sudo.

There are a few issues for another bug report with nolocal.net rules as distributed.

I still like firejail I'm just surprised by this.

@h1z1 commented on GitHub (Feb 13, 2016): Understood, I do think of it as a shield, that is the problem. Indeed it is in the man page too. That doesn't negate that I didn't know however. By doing so you've essentially taken the systemd approach - bypass any OS protections because we know better. That is a bit troubling. I would personally prefer forcing root to setup jails or use sudo. There are a few issues for another bug report with nolocal.net rules as distributed. I still like firejail I'm just surprised by this.

gitea-mirror commented

2026-05-05 05:18:56 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 14, 2016):

Indeed it is in the man page too. That doesn't negate that I didn't know however.

You should always consult the project page: http://firejail.wordpress.com

I would personally prefer forcing root to setup jails or use sudo.

This mode of operation is already supported. Servers are started this way in Firejail. You can even turn off SUID bit:

$ sudo chmod u-s /usr/bin/firejail

Open a new terminal and start the sandbox as root:

$ sudo firejail

Inside the sandbox you'll need to su into your own account. After that you can run any program you want. Maybe you'll need to adjust some of the profiles.

There are a few issues for another bug report with nolocal.net rules as distributed.

Send them in and I'll fix them. nolocal.net is a pretty recent feature.

@netblue30 commented on GitHub (Feb 14, 2016): > Indeed it is in the man page too. That doesn't negate that I didn't know however. You should always consult the project page: http://firejail.wordpress.com > I would personally prefer forcing root to setup jails or use sudo. This mode of operation is already supported. Servers are started this way in Firejail. You can even turn off SUID bit: ``` $ sudo chmod u-s /usr/bin/firejail ``` Open a new terminal and start the sandbox as root: ``` $ sudo firejail ``` Inside the sandbox you'll need to su into your own account. After that you can run any program you want. Maybe you'll need to adjust some of the profiles. > There are a few issues for another bug report with nolocal.net rules as distributed. Send them in and I'll fix them. nolocal.net is a pretty recent feature.

gitea-mirror commented

2026-05-05 05:18:57 -06:00

Author

Owner

@stiell commented on GitHub (Mar 4, 2016):

What about @yumkam's original proposal:

IMO, there should be (root-only writable) policy file, that restrict set of allowed interfaces, […]. By default, it should allow only --net=none;

This would fit my use case perfectly, where I have created a separate bridge interface for jails and use iptables on the "host" side to forward and masquerade packets from this interface. I only want firejail to be able to access this particular interface.

@stiell commented on GitHub (Mar 4, 2016): What about @yumkam's original proposal: > IMO, there should be (root-only writable) policy file, that restrict set of allowed interfaces, […]. By default, it should allow only `--net=none`; This would fit my use case perfectly, where I have created a separate bridge interface for jails and use iptables on the "host" side to forward and masquerade packets from this interface. I only want firejail to be able to access this particular interface.

gitea-mirror commented

2026-05-05 05:18:59 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 4, 2016):

@yumkam added support to restrict the network at compile time. Run "./configure --prefix=/usr --enable-network=restricted", then compile as usual. This will only allow --net=none for regular users.

@netblue30 commented on GitHub (Mar 4, 2016): @yumkam added support to restrict the network at compile time. Run "./configure --prefix=/usr --enable-network=restricted", then compile as usual. This will only allow --net=none for regular users.

gitea-mirror commented

2026-05-05 05:19:00 -06:00

Author

Owner

@yumkam commented on GitHub (Mar 4, 2016):

well, @stell wants something more permissive. E.g. see yumkam/firejail@838758f (not sure if this approach is right, so not a pull request yet).

@yumkam commented on GitHub (Mar 4, 2016): well, @stell wants something more permissive. E.g. see yumkam/firejail@838758f (not sure if this approach is right, so not a pull request yet).

gitea-mirror commented

2026-05-05 05:19:03 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 5, 2016):

OK, let's do like this:

I'll add support to read from /etc/firejail/firejail.conf run-time configuration information, something similar to /etc/ssh/sshd_config. We also keep configure.ac support, and we then can add any other new features necessary.

@netblue30 commented on GitHub (Mar 5, 2016): OK, let's do like this: I'll add support to read from /etc/firejail/firejail.conf run-time configuration information, something similar to /etc/ssh/sshd_config. We also keep configure.ac support, and we then can add any other new features necessary.

gitea-mirror referenced this issue

2026-05-05 10:03:44 -06:00

[PR #202] [MERGED] Allow netlink for Spotify #3564

Rows
Columns

[GH-ISSUE #290] firejail allows regular users to assign arbitrary address (IP, MAC) on any network interface #202