mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3754] Can't run Discord with Linux-Hardened kernel #2367
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2367
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @seonwoolee on GitHub (Nov 15, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3754
Bug and expected behavior
To be clear, I'm not calling this a bug, but seeking support.
Discord works perfectly fine with the default profile and default kernel on my Arch Linux system. However, when I use the linux-hardened kernel, I get the error
The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/discord/chrome-sandbox is owned by root and has mode 4755And
/opt/discord/chrome-sandboxdoes have the correct permissions (because again, this works perfectly fine with the standard Linux kernel.How can I determine what kernel parameter I need to change to make this work while using the hardened kernel?
Environment
Checklist
https://github.com/netblue30/firejail/issues/1139)--profile=PROFILENAMEis used to set the right profile.LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 PROGRAMto get english error-messages.debug output
@bbhtt commented on GitHub (Nov 15, 2020):
What does
cat /proc/sys/kernel/unprivileged_userns_clonesay?Your options:
A) Try commenting
caps.drop all, noroot, nonewprivs, protocolandseccompin/etc/firejail/discord-common.profileif it works with that only that it's good but Firejail's sandbox becomes loose. Thecaps.drop allcan be changed tocaps.keepand similarlyseccompif it works.B) Turn that sysctl knob and use firejail.
C) Disable internal sandbox of chromium with
--no-sandbox. (This might not work with recent electron versions)I suggest B and C as a last resort since both have security implications.
@rusty-snake commented on GitHub (Nov 15, 2020):
Additions:
A) The
caps.keepline would becaps.keep sys_admin,sys_chroot.C) There is also a
--disable-setuid-sandboxswitch AFAICTY.@seonwoolee commented on GitHub (Nov 15, 2020):
A) didn't work at all unfortunately.
B) works
C) Did you mean
firejail --no-sandbox discordandfirejail --disable-setuid-sandbox discord? Because neither of them are recognized as valid parameters to firejail@rusty-snake commented on GitHub (Nov 16, 2020):
A) What's in your globals.local?
C) To "Disable [the] internal sandbox of chromium" you need to add these parameters to discord:
firejail discord --no-sandboxorfirejail discord --disable-setuid-sandbox.@seonwoolee commented on GitHub (Nov 17, 2020):
A) Nothing
C) Gotcha.
--no-sandboxworks,--disable-setuid-sandboxdoes not@bbhtt commented on GitHub (Nov 17, 2020):
I suggest going with (B) because:
Reduce profile maintenance since all electron applications will be affected.
Enjoy advantage of both Firejail and chromium-sandbox.
But do know that while no mainline distro kernels except Debian and RHEL(see below) ship with that patch there are security reasons for enabling it. That's why non-mainline/hardened kernels have it. You can find information on Security SE and LWN threads. Here are some newer CVEs (older on SSE threads) relating to it:
(1) https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-14386.html
(2) https://nvd.nist.gov/vuln/detail/CVE-2019-20794
(3) https://security.archlinux.org/CVE-2020-16120
Bottomline: (+) With that any container or sandbox won't work; browser sandbox take advantage of it; reduces usability.
(-) Priv esc/root exploit vulns..
Debian is going to reconsider that patch in the next year since at the time of enabling it 5-6 years it was said to be a temporary mitigation.
Kernel thread: https://lkml.org/lkml/2016/1/22/7
Firejail thread: https://github.com/netblue30/firejail/issues/ 1347
About --no-sandbox it disables chromium's internal sandbox; you rely entirely on Firejail to sandbox. Comparison between the two:
https://github.com/netblue30/firejail/issues/ 554
Firejail offers more granular permissions like directory restrictions,dbus restrictions, apparmor,selinux,shell/lib/bin/program restrictions etc. Bottomline here: I recommend not disabling the internal sandbox of chromium if you are able.
Feel free to correct me/add.
On November 17, 2020 3:45:47 AM UTC, Seonwoo Lee notifications@github.com wrote:
@rusty-snake commented on GitHub (Nov 17, 2020):
force-nonewprivs yesin/etc/firejail/firejail.configSince we need to fix such things upstream anyway, you need to add
nonewprivs,caps.drop all, ... after the next firejail update manualyAFAIK only Debian and ArchLinux have this patch (Arch: linux has it opt-in via sysctl and linux-hardened has it opt-out via sysctl Debian: always opt-out).
Mainline/Fedora/RHEL: Don't have this patch. However RHEL (but not Fedora) disables userns completely by default via
user.max_user_namespaces=0AFAIK (is there a difference between 7 and 8?).The main argument is that some exploits (user to root) require unprivileged userns. On the other hand you can remove the setuid bit from bwrap, chrome-sandbox and vivaldi-sandbox if you enable unprivileged userns. This prevents other user to root exploits which are unrelated to userns but require suid.
The debug log says
~.config/firejail/globals.localis read. If this file is empty, you can remove it for performance reasons (less disk I/O on sandbox startup).Have you set
force-nonewprivs yesin/etc/firejail/firejail.config?@seonwoolee commented on GitHub (Nov 20, 2020):
Gotcha, I'll go with B) then.
I hadn't set
force-nonewprivs yes, doing that now