mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #6368] chromium: failure due to AppArmor user namespace errors #3252
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#3252
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 @luckylinux on GitHub (Jun 3, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6368
Description
Trying to run Chromium results in a AppArmor "DENIED" Message in
dmesg.Steps to Reproduce
Run in BASH
firejail /usr/bin/chromium.Result:
I also tried to add a Custom AppArmor Profile in
/etc/apparmor.d/chromiumand Issueingsystemctl restart apparmorbut this does NOT solve the Issue:Expected behavior
Chromium starting normally.
Actual behavior
Chromium refuses to start.
Behavior without a profile
What changed calling
LC_ALL=C firejail --noprofile /path/to/programin aterminal?
It actually works (or at least starts ...)
Additional context
Any other detail that may help to understand/debug the problem
Relevant
/etc/sysctl.d/99-userns.confthat might be responsible for the Issue:Relevant
dmesgOutput:Environment
Checklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
Output of
LC_ALL=C firejail /path/to/programOutput of
LC_ALL=C firejail --debug /path/to/program@ghost commented on GitHub (Jun 3, 2024):
Is this a file installed by your OS? Or did you add it yourself? Also, please add your OS and firejail version to the report.
For now I see a few ways to try to get chromium to work as expected. Please test the below
chromium-common.localoverrides one by one and report back the result of each attempt.@luckylinux commented on GitHub (Jun 3, 2024):
I added the File
/etc/sysctl.d/99-userns.confmyself.According to https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces Ubuntu should enforce AppArmor Profiles by default now, but lots of back and forths while trying to have a Hardened GNU/Linux System, especially with Electron Apps refusing to work (particularly Bitwarden AppImage).
Hence I prefer to show the File that reflects the current Configuration.
(More or less) same Result as before
Chromium starts, but Keyboard disabled (
GTK_IM_MODULE=ximmight solve this, untested).Possible Typo in your File ?
userns_createis not recognized@ghost commented on GitHub (Jun 3, 2024):
Thanks for testing.
No change, so we can focus on the alternatives.
For the moment this seems to be the
most promisingcandidate to fix this. Obviously we need to adress the keyboard issue. Also, the (new?) SSL-related error is a bit unexpected:My bad. I took
userns_createstraight from your posted dmesg output above. I'll do some more digging, but it would be nice to try dropping the caps option alltogether:To confirm that Firejail can actually sandbox chromium properly in combination with your AppArmor profile we also need to test if it works with our
noprofile.profile. This offers the weakest possible sandbox Firejail can apply to a program, and a such is considered useful for debugging purposes only.Hope we can fix this properly and securely :)
@luckylinux commented on GitHub (Jun 3, 2024):
Nah ... I omitted some part of the Logs, because it concerns a self-signed SSL Certificate (default OPNSense self-signed SSL Certificate). I assume this is also related to that.
Now you are suggesting a different File (
~/.config/firejail/chromium-common.profilevs the previous~/.config/firejail/chromium-common.local). Is this intentional ?If I do with
~/.config/firejail/chromium-common.local(same filename as before) with justignore caps.keepI get:With your new proposed Filename (
~/.config/firejail/chromium-common.profile) I get instead (with the same Contents):Chromium starts, but Keyboard isn't working.
The following makes the Keyboard also work, although not sure about this being a long-term Solution:
For Reference File
/usr/lib/x86_64-linux-gnu/firejail/seccomp.debug32does NOT exist.Contents of Folder
ls -la /usr/lib/x86_64-linux-gnu/firejailI also hope that. I was NOT using ANY sandboxing until now 👎, but given how many exploits and vulnerabilities, "hoping" is NOT a Plan.
I also read that firejail is probably insecure on its own (due to the
setuidbit etc), and Bubblewrap /bwrapmight be better and so on ... Yet Bubblewrap isn't really User-friendly IMHO 😞, so at least firejail should be a good additional Layer of Protection ... at least for the foreseable Future.This isn't yet taking care of X11 Sandboxing of course. Launching
firejailwith--x11=xpradoesn't work (it just crashes), while I could play a bit around yesterday and got it to worth with Thunderbird (firejail --x11=xephyr thunderbird).@ghost commented on GitHub (Jun 3, 2024):
Observations on your latest round of testing:
Glad to read that the SSL-related output isn't a breakage factor.
Good that you caught my mistake, it was indeed the intention to test with ~/.config/firejail/chromium-common.local. Now we've confirmed tha it's not a fix, we can skip this option.
Good news! Happy that this is working, regardless of the keyboard side-issue. Now it's a matter of tracking down the culprit option(s) and implement a proper, secure chromium sandbox.
Regarding that keyboard aspect, having to use
GTK_IM_MODULE=ximisn't that uncommon or insecure. You will need this, now as well as in a future Firejail release. Because we don't know if, nor which IM module users prefer to use, it would be pointless to put this environment variable in the profile. But you as user definitely can. The supported syntax for doing so is documented in the man page, but rather straightforward:env GTK_IM_MODULE=xim.Due to Firejail's support for both 32bit and 64bit OSes this is a
common and ignorableoutput on a 64bit system. I realize that it's hard to distinguish at first between what's okay and what's not in (some of) the more verbose (debug) output Firejail can throw. Your keen eye for details (e.g. like catching on to my mistakes), context-awareness during this troubleshooting session, etcetera, that indicates you're going to do just fine with sandboxing. Whether using Firejail or alternative tech, that's not for me to decide or try to influence by glossing over some 'facts' about the limitations of such endeavours.Which brings us to the
setuidtopic. Users should be very much aware of the implications of running a SUID binary, be it firejail, pkexec, sudo, su or others. Yes, all of these well-known other layers we use without giving it much thought, are also setuid/setgid. Reading up is always something to be stimulated. And it's not getting any less complex/complicated 'out there' is it? :)What Firejail is concerned, there are documented
mitigations. Here are some links on that topic:Definately a powerful set of options. And there's also Wayland getting more and more polished for daily use. Sadly, Firejail's
--x11=xorgoption doesn't work for chromium (and xterm). There's some more context provided inman firejailon this topic.That's it for now. Enjoy!
@luckylinux commented on GitHub (Jun 3, 2024):
Isn't this something that can be set on a "global" level ? I'm tempted to say
~/.bashrcand/or~/.bash_profile, but since this is firejail-specific, maybe there is a way for a "common" include (like for instance/etc/firejail/disable-common.inc, but NOT for disabling stuff and in my User Folder) ?I think both
geany,chromium,thunderbirdand probably several other are affected by the same Issue.Actually I set
force-nonewprivs yesin/etc/firejail/firejail.config.Maybe the Chromium Issue is related to this actually (although
kernel.unprivileged_userns_clone=1and NOT 0) ?Although I find it a bit weird that this isn't something "standardized" in the "normal" (shipped) Chromium profile, isn't it ?
I just sense that it's going to maybe fix 1 Issue while creating 10 new ones 😞.
Thanks for your help 👍.
I guess, as usual, it's like opening a Pandora Box. You know where you start, you do NOT know where you end up 😆.
@ghost commented on GitHub (Jun 3, 2024):
Follow-up
Not my best day apparently. There's something I have overlooked.
To actually test this in combination with Firejail's apparmor option there's two conditions that need to be fulfilled:
So, if you're up for it (doesn't have to be right now of course), it might try this again. After all, if it's possible, that would provide the 'ideal' fix.
(1) the Firejail part (we've done similarly above)
(2) the AppArmor part
Additionally, to absolutely make sure this AA profile makes it into kernelspace, a reboot is advised instead of restarting the apparmor.service.
Fingers crossed!
@ghost commented on GitHub (Jun 3, 2024):
GTK_IM_MODULE=ximAbsolutely. Like two sides of a coin. Do it in your desktop environment via shell configuration like you mentioned (per-user) or (system-wide) via
/etc/bash.bashrc. Additionally try setting it in Firejail's sandbox. Easiest is using~/.config/firejail/globals.local. That way it'll get included in (almost) all profiles and - as far as I can see - doing so won't break sandboxed CLI programs that don't need it. Thatglobals.localis a very powerful built-in override. If you don't have one yet, my guess is you'll soon see its advantages and create one :)force-nonewprivsThat's a wise decision. But be/stay aware of the implications. Wireshark for example will
breakunder these conditions. Likely others, but very few. And the settings in firejail.config aren't run-time ones, hence a bit awkward to override. Alternatively you can keep the default in firejail.config and set it in the aforementionedglobals.local. Less hassle, same effect. Just my $ 0.02 :)Believe it or not, but I don't use Chromium and don't even have it installed. Just a personal thing, unrelated to security and/or sandboxing. TL;DR can't be sure if enforcing nonewprivs is the cause of all this. But I'd definitely try that!
Ciao
@luckylinux commented on GitHub (Jun 3, 2024):
Will try to Reboot at some Point ...
@luckylinux commented on GitHub (Jun 3, 2024):
Thanks again 👍.
To be honest I use Firefox as my Daily Driver, but I sometimes need a "Backup" to cross-check some of the weird Issues I sometimes encounter with Firefox (SSL Certificates, Authentication, Cache of Credentials, etc).
@gcqmkm02 commented on GitHub (Aug 29, 2024):
Tengo lo mismo problema con el flatpak.
Despues de hacer
sd sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
los flatpaks funcionan.