Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does changing $PATH affect the security? #3552

Closed
TheEvilSkeleton opened this issue Jul 26, 2020 · 4 comments
Closed

Does changing $PATH affect the security? #3552

TheEvilSkeleton opened this issue Jul 26, 2020 · 4 comments

Comments

@TheEvilSkeleton
Copy link

TheEvilSkeleton commented Jul 26, 2020

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

image

image

Is his claim about changing $PATH true?

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

@rusty-snake
Copy link
Collaborator

  1. True, but not on a release. Only the git version between DHCP client support #3102 and Harden dhcp by checking for /sbin/dhclient #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. Firejail worsen security? #3046

@rusty-snake
Copy link
Collaborator

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

@TheEvilSkeleton
Copy link
Author

  1. Firejail worsen security? #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 (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!

@rusty-snake
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants