github-starred/firejail

Fork 0

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

[GH-ISSUE #3552] Does changing $PATH affect the security? #2232

New issue

Closed

opened 2026-05-05 08:55:24 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:55:24 -06:00

Owner

Originally created by @TheEvilSkeleton on GitHub (Jul 26, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3552

Hello, I've had an argument with someone about Firejail. He claimed that any attacker can easily change the $PATH to disable Firejail, and then said that Firejail does more harm than good:

Is his claim about changing $PATH true?

Will it actually harm even more than running a program normally?

Originally created by @TheEvilSkeleton on GitHub (Jul 26, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3552 Hello, I've had an argument with someone about Firejail. He claimed that any attacker can easily change the $PATH to disable Firejail, and then said that Firejail does more harm than good: ![image](https://user-images.githubusercontent.com/50847364/88482529-dad49980-cf2f-11ea-9c09-48ef5a453418.png) ![image](https://user-images.githubusercontent.com/50847364/88482592-4dde1000-cf30-11ea-8a57-15a7458b4a14.png) ![image](https://user-images.githubusercontent.com/50847364/88482583-3bfc6d00-cf30-11ea-8561-67d54fffedad.png) Is his claim about changing $PATH true? Will it actually harm even more than running a program normally?

gitea-mirror

2026-05-05 08:55:24 -06:00

closed this issue
added the
security
label

gitea-mirror commented

2026-05-05 08:55:27 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 26, 2020):

True, but not on a release. Only the git version between #3102 and #3239.
An attacker from outside the sandbox can start a program w/o firejail. However if an attacker can execute code on your system this is irrelevant.
#3046

@rusty-snake commented on GitHub (Jul 26, 2020): 1. True, but not on a release. Only the git version between #3102 and #3239. 2. An attacker from outside the sandbox can start a program w/o firejail. However if an attacker can execute code on your system this is irrelevant. 3. #3046

gitea-mirror commented

2026-05-05 08:55:28 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 26, 2020):

The attack surface for a sandboxed program is lower/minimized. The attack surface for a unsandboxed program is increased.

Firejails initial commit: d1af2f5ba7 (August 2015)
Last priv-esc CVE: https://www.cvedetails.com/cve/CVE-2017-5940/ (2017)
=> All +Priv CVEs were is the first two year, where firejail was a young project.

@rusty-snake commented on GitHub (Jul 26, 2020): 3. The attack surface for a sandboxed program is lower/minimized. The attack surface for a unsandboxed program is increased. Firejails initial commit: https://github.com/netblue30/firejail/commit/d1af2f5ba705edf9662fe5aaa1259fbdc5258e70 (August 2015) Last priv-esc CVE: https://www.cvedetails.com/cve/CVE-2017-5940/ (2017) => All +Priv CVEs were is the first two year, where firejail was a young project.

gitea-mirror commented

2026-05-05 08:55:29 -06:00

Author

Owner

@TheEvilSkeleton commented on GitHub (Jul 26, 2020):

https://github.com/netblue30/firejail/issues/3046

Well that was a fun read...

The attack surface for a sandboxed program is lower/minimized. The attack surface for a unsandboxed program is increased.

Firejails initial commit: d1af2f5 (August 2015)
Last priv-esc CVE: https://www.cvedetails.com/cve/CVE-2017-5940/ (2017)
=> All +Priv CVEs were is the first two year, where firejail was a young project.

Closing the issue. That seems enough information for me to stay on Firejail. Thank you so much for the very quick responses!

@TheEvilSkeleton commented on GitHub (Jul 26, 2020): > 3. https://github.com/netblue30/firejail/issues/3046 Well that was a fun read... > 1. The attack surface for a sandboxed program is lower/minimized. The attack surface for a unsandboxed program is increased. > > Firejails initial commit: [d1af2f5](https://github.com/netblue30/firejail/commit/d1af2f5ba705edf9662fe5aaa1259fbdc5258e70) (August 2015) > Last priv-esc CVE: https://www.cvedetails.com/cve/CVE-2017-5940/ (2017) > => All +Priv CVEs were is the first two year, where firejail was a young project. Closing the issue. That seems enough information for me to stay on Firejail. Thank you so much for the very quick responses!

gitea-mirror commented

2026-05-05 08:55:31 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 27, 2020):

To extend: On a desktop-system the most common way to get root is to map sudo to an script which catch the password, because nobody verifies each time that he is executing /usr/bin/sudo. There is no need for 0-days if you have a user 🤓 .

However why should an attacker on a desktop-system be interested in becoming root? Ransomware, spyware, botnets, ... all work with normal rights. They can access the internet (if connected), encrypt/delete/upload your files, access network shares, ...

You can additional harden firejail in firejail.config (usually found in /etc/firejail):

# force-nonewprivs make the most privilege-escalations unexploitable.
# Downside: You can no longer sandbox privileged-programs such as ping, chromium, wireshark.
force-nonewprivs yes

# Allow only root to use networking features (exception: --net=none)
# This breaks also the $PATH+dhclient EoP from above.
restricted-network yes

# Disable networking features entirely for all users including root (exception: --net=none)
network no

# What you do not use can be disabled, and then it cannot be exploited.
# Attention: disabling features such as whitelist will drastically weak sandboxes which is disproportionate to the security gain.
# Other features such as cgroup or chroot can safely be disabled.
bind no
cgroup no
chroot no
file-transfer no
join no
overlayfs no
private-home no
private-lib no
seccomp no
userns no
whitelist no
x11 no

@rusty-snake commented on GitHub (Jul 27, 2020): To extend: On a desktop-system the most common way to get root is to map `sudo` to an script which catch the password, because nobody verifies each time that he is executing `/usr/bin/sudo`. There is no need for 0-days if you have a user :nerd_face: . However why should an attacker on a desktop-system be interested in becoming root? Ransomware, spyware, botnets, ... all work with normal rights. They can access the internet (if connected), encrypt/delete/upload your files, access network shares, ... ---- You can additional harden firejail in `firejail.config` (usually found in `/etc/firejail`): ``` # force-nonewprivs make the most privilege-escalations unexploitable. # Downside: You can no longer sandbox privileged-programs such as ping, chromium, wireshark. force-nonewprivs yes # Allow only root to use networking features (exception: --net=none) # This breaks also the $PATH+dhclient EoP from above. restricted-network yes # Disable networking features entirely for all users including root (exception: --net=none) network no # What you do not use can be disabled, and then it cannot be exploited. # Attention: disabling features such as whitelist will drastically weak sandboxes which is disproportionate to the security gain. # Other features such as cgroup or chroot can safely be disabled. bind no cgroup no chroot no file-transfer no join no overlayfs no private-home no private-lib no seccomp no userns no whitelist no x11 no ```

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2232

No description provided.

Rows
Columns