[GH-ISSUE #2665] Malware can bypass host's firewall using firejail --net=...

gitea-mirror commented

2026-05-05 08:19:35 -06:00

Owner

Originally created by @dandelionred on GitHub (Apr 25, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2665

Hey guys! I'm slightly :) paranoid mby but still.

Setup:

openvpn client
default output policy is DROP
outgoing traffic is only allowed to
- lo device
- local networks
- openvpn server
- tun0 device

This way my external traffic either goes into tun0 or goes nowhere in case the openvpn connection dies whatever the reason, so my real external ip is never leaked.

Firejail present on my system opens an attack vector for malware to leak my real ip like this:

firejail --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 curl icanhazip.com

(because the newly created network namespace is absolutely independ of the host's network namespace were my firewall rules exist)

Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it).

Another point of view: the recommended way to sandbox x11 unintentionally ignores the host's firewall

firejail --x11 --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 firefox

Btw --net is not a must to disable the abstract x11 sockets. With this https://tstarling.com/blog/2016/06/x11-security-isolation/ I successfully shut those down in ubuntu 14.04:

/etc/lightdm/lightdm.conf.d/50-X-no-listen.conf

[SeatDefaults]
xserver-command=X -nolisten local

Is it possible to disable the "--net" feature at all at compile time?

Originally created by @dandelionred on GitHub (Apr 25, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2665 Hey guys! I'm slightly :) paranoid mby but still. Setup: - openvpn client - default output policy is DROP - outgoing traffic is only allowed to - lo device - local networks - openvpn server - tun0 device This way my external traffic either goes into tun0 or goes nowhere in case the openvpn connection dies whatever the reason, so my real external ip is never leaked. Firejail present on my system opens an attack vector for malware to leak my real ip like this: ``` firejail --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 curl icanhazip.com ``` _(because the newly created network namespace is absolutely independ of the host's network namespace were my firewall rules exist)_ Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it). Another point of view: the recommended way to sandbox x11 unintentionally ignores the host's firewall ``` firejail --x11 --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 firefox ``` Btw `--net` is not a must to disable the abstract x11 sockets. With this https://tstarling.com/blog/2016/06/x11-security-isolation/ I successfully shut those down in ubuntu 14.04: /etc/lightdm/lightdm.conf.d/50-X-no-listen.conf ``` [SeatDefaults] xserver-command=X -nolisten local ``` **Is it possible to disable the "--net" feature at all at compile time?**

gitea-mirror closed this issue

2026-05-05 08:19:36 -06:00

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Apr 25, 2019):

This is already supported: uncomment and set restricted-network to yes in /etc/firejail/firejail.config. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/

malware can bypass it

at that point, you're already compromised anyway

Off-topic: instead of relying on fragile iptable rules to ensure your routing, consider using Qubes+Whonix or Tails

@SkewedZeppelin commented on GitHub (Apr 25, 2019): This is already supported: uncomment and set `restricted-network` to `yes` in `/etc/firejail/firejail.config`. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/ > malware can bypass it at that point, you're already compromised anyway Off-topic: instead of relying on fragile iptable rules to ensure your routing, consider using Qubes+Whonix or Tails

gitea-mirror commented

2026-05-05 08:19:38 -06:00

Author

Owner

@veloute commented on GitHub (Apr 26, 2019):

if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address.

@veloute commented on GitHub (Apr 26, 2019): if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address.

gitea-mirror commented

2026-05-05 08:19:39 -06:00

Author

Owner

@dandelionred commented on GitHub (Apr 26, 2019):

@SkewedZeppelin

This is already supported: uncomment and set restricted-network to yes in /etc/firejail/firejail.config. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/

I compiled it myself. Thanks for the tip, I'll use the config option.

malware can bypass it

at that point, you're already compromised anyway

I don't share your point of view. Thinking in terms of "compromised anyway" it would be OK having passwordless sudo.

@veloute

if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address.

Do you use passwordless sudo?

@dandelionred commented on GitHub (Apr 26, 2019): @SkewedZeppelin > This is already supported: uncomment and set `restricted-network` to `yes` in `/etc/firejail/firejail.config`. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/ I compiled it myself. Thanks for the tip, I'll use the config option. > > malware can bypass it > > at that point, you're already compromised anyway I don't share your point of view. Thinking in terms of "compromised anyway" it would be OK having passwordless sudo. @veloute > if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address. Do you use passwordless sudo?

gitea-mirror commented

2026-05-05 08:19:40 -06:00

Author

Owner

@veloute commented on GitHub (Apr 26, 2019):

Do you use passwordless sudo?

see https://xkcd.com/1200/

@veloute commented on GitHub (Apr 26, 2019): > Do you use passwordless sudo? see https://xkcd.com/1200/

gitea-mirror commented

2026-05-05 08:19:40 -06:00

Author

Owner

@dandelionred commented on GitHub (Apr 26, 2019):

@veloute

Do you use passwordless sudo?

see https://xkcd.com/1200/

There is a big flaw in the comic: you have to have friends for someone to impersonate to.
Joking aside, the comic (while still hitting some point) is poor minded

@dandelionred commented on GitHub (Apr 26, 2019): @veloute > > Do you use passwordless sudo? > > see https://xkcd.com/1200/ There is a big flaw in the comic: you have to have friends for someone to impersonate to. Joking aside, the comic (while still hitting some point) is poor minded

gitea-mirror commented

2026-05-05 08:19:41 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Apr 26, 2019):

see https://xkcd.com/1200/

This is why you don't remain logged in and make it easy to revoke authorization for programs that are logged in. For example, I run fetchmail, but it has its own app password which I can then revoke should the need arise.

Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well,

So yeah, the comic isn't really all that valid.

@chiraag-nataraj commented on GitHub (Apr 26, 2019): > see https://xkcd.com/1200/ This is why you don't remain logged in and make it easy to revoke authorization for programs that _are_ logged in. For example, I run `fetchmail`, but it has its own app password which I can then revoke should the need arise. Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well, So yeah, the comic isn't _really_ all that valid.

gitea-mirror commented

2026-05-05 08:19:41 -06:00

Author

Owner

@veloute commented on GitHub (Apr 26, 2019):

There is a big flaw in the comic: you have to have friends for someone to impersonate to.
Joking aside, the comic (while still hitting some point) is poor minded

This is why you don't remain logged in and make it easy to revoke authorization for programs that are logged in. For example, I run fetchmail, but it has its own app password which I can then revoke should the need arise.

Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well,

So yeah, the comic isn't really all that valid.

i see your point - it probably isn't the best example but was the best one i could think of at the time.
a better example of the point i was trying to make was maybe https://en.wikipedia.org/wiki/Principle_of_least_privilege

essentially, what i was trying to say is that a process doesn't necessarily need to have elevated privileges to wreak havoc for a user and cause all kinds of damage - generally speaking, most users have quite a lot of important documents stored in a regular, user-accessible directories.

if a process can run arbitrary commands on a system, they can, for example:

force remove all files it has write access to.
download and run anything.
kill other user processes.
etc.

from the op:

Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it).

it's a lot harder to stop malware from doing things once it's in, that's why we take precautions so it can't get in the system in the first place.

firejail is essentially an answer to that problem. if a process is isolated using firejail, it wouldn't be able to do the command first mentioned, so i'd argue the problem is moot.

@veloute commented on GitHub (Apr 26, 2019): > There is a big flaw in the comic: you have to have friends for someone to impersonate to. > Joking aside, the comic (while still hitting some point) is poor minded > This is why you don't remain logged in and make it easy to revoke authorization for programs that _are_ logged in. For example, I run `fetchmail`, but it has its own app password which I can then revoke should the need arise. > > Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well, > > So yeah, the comic isn't _really_ all that valid. i see your point - it probably isn't the best example but was the best one i could think of at the time. a better example of the point i was trying to make was maybe https://en.wikipedia.org/wiki/Principle_of_least_privilege essentially, what i was trying to say is that a process doesn't necessarily need to have elevated privileges to wreak havoc for a user and cause all kinds of damage - generally speaking, most users have quite a lot of important documents stored in a regular, user-accessible directories. if a process can run arbitrary commands on a system, they can, for example: - force remove all files it has write access to. - download and run anything. - kill other user processes. - etc. from the op: > Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it). it's a lot harder to stop malware from doing things once it's in, that's why we take precautions so it can't get in the system in the first place. firejail is essentially an answer to that problem. if a process is isolated using firejail, it wouldn't be able to do the command first mentioned, so i'd argue the problem is moot.

gitea-mirror commented

2026-05-05 08:19:42 -06:00

Author

Owner

@dandelionred commented on GitHub (Apr 26, 2019):

that's why we take precautions so it can't get in the system in the first place.

Check this out:

So it is pretty possible to have malware installed by just upgrading some application from pip/npm.

After all, I'd like to take back my thoughts about the horrible possibility for malware to leak my ip by means of firejail --net.

I'd even say more: it doesn't matter much if your sudo is passwordless or not on a generic xorg desktop (not speaking about qubes). As only malware can run anything under the user, in can either use the passwordless sudo OR keylog with xinput until you enter the password. Some creepy details: https://security.stackexchange.com/a/119420

@dandelionred commented on GitHub (Apr 26, 2019): > that's why we take precautions so it can't get in the system in the first place. Check this out: - https://stackoverflow.com/questions/38236366/are-pip-packages-curated-is-it-safe-to-install-them - https://searchsecurity.techtarget.com/news/252453398/Compromised-NPM-package-highlights-open-source-trouble So it is pretty possible to have malware installed by just upgrading some application from pip/npm. --- After all, I'd like to take back my thoughts about the _horrible_ possibility for malware to leak my ip by means of firejail --net. I'd even say more: it doesn't matter much if your sudo is passwordless or not on a generic xorg desktop (not speaking about qubes). As only malware can run anything under the user, in can either use the passwordless sudo OR keylog with xinput until you enter the password. Some creepy details: https://security.stackexchange.com/a/119420

gitea-mirror commented

2026-05-05 08:19:42 -06:00

Author

Owner

@dandelionred commented on GitHub (Apr 26, 2019):

Back to the stolen laptop story: you're not safe even in case you have the screen locked the stock way. That's why this exists https://github.com/google/xsecurelock

@dandelionred commented on GitHub (Apr 26, 2019): Back to the _stolen laptop_ story: you're not safe even in case you have the screen locked the stock way. That's why this exists https://github.com/google/xsecurelock

gitea-mirror commented

2026-05-05 08:19:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Apr 26, 2019):

So it is pretty possible to have malware installed by just upgrading some application from pip/npm.

I mean, yeah. Just like it's possible to get malware on Windows by downloading random applications. I really don't see a difference here.

As for the other stuff, I'm not quite sure what your point is. Yeah, X11 is insecure - I feel like many people here already know that. We can try to use X11 isolation through firejail (using either xpra or xephyr), but everything's imperfect.

And yeah, all those environment variables are both useful and dangerous - one does not preclude the other. firejail strips many environment variables out of the environment passed to the child process, so that helps a bit.

I guess, fundamentally, I'm not quite sure what your point is anymore.

@chiraag-nataraj commented on GitHub (Apr 26, 2019): > So it is pretty possible to have malware installed by just upgrading some application from pip/npm. I mean, yeah. Just like it's possible to get malware on Windows by downloading random applications. I really don't see a difference here. As for the other stuff, I'm not _quite_ sure what your point is. Yeah, X11 is insecure - I feel like many people here already know that. We can try to use X11 isolation through `firejail` (using either `xpra` or `xephyr`), but everything's imperfect. And yeah, all those environment variables are both _useful_ and _dangerous_ - one does not preclude the other. `firejail` strips many environment variables out of the environment passed to the child process, so that helps a bit. I guess, fundamentally, I'm not quite sure what your point is anymore.

gitea-mirror commented

2026-05-05 08:19:43 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 26, 2019):

Regarding the original issue, I still wonder if there could be another way than disabling the networking features altogether.

For example, it might be possible to save the current ipfilter configuration into a file before the sandbox process is created, and then always apply this firewall in the new net namespace. This could be made configurable in firejail.config.

@smitsohu commented on GitHub (Apr 26, 2019): Regarding the original issue, I still wonder if there could be another way than disabling the networking features altogether. For example, it might be possible to save the current ipfilter configuration into a file before the sandbox process is created, and then always apply this firewall in the new net namespace. This could be made configurable in firejail.config.

Rows
Columns

[GH-ISSUE #2665] Malware can bypass host's firewall using firejail --net=... #1678