chromium: failure due to AppArmor user namespace errors #6368
Comments
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
$ cat ~/.config/firejail/chromium-common.local
apparmor /usr/bin/chromium
$ cat ~/.config/firejail/chromium-common.local
ignore apparmor
$ cat ~/.config/firejail/chromium-common.local
caps.keep sys_admin,sys_chroot,userns_create
ignore caps.keep |
I added the File 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 (
Possible Typo in your File ? |
|
Thanks for testing.
No change, so we can focus on the alternatives.
For the moment this seems to be the
My bad. I took $ ~/.config/firejail/chromium-common.profile
ignore caps.keepTo confirm that Firejail can actually sandbox chromium properly in combination with your AppArmor profile we also need to test if it works with our $ firejail --profile=noprofile /usr/bin/chromiumHope we can fix this properly and securely :) |
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 ( If I do with With your new proposed Filename (
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
I 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 This isn't yet taking care of X11 Sandboxing of course. Launching |
|
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.
Due to Firejail's support for both 32bit and 64bit OSes this is a Which brings us to the
Definately a powerful set of options. And there's also Wayland getting more and more polished for daily use. Sadly, Firejail's That's it for now. Enjoy! |
Isn't this something that can be set on a "global" level ? I'm tempted to say I think both
Actually I set 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 😆. |
|
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) $ cat ~/.config/firejail/chromium-common.local
apparmor /usr/bin/chromium(2) the AppArmor part # use proper AA naming scheme
$ sudo mv /etc/apparmor.d/chromium /etc/apparmor.d/usr.bin.chromium
# purge AA cache
$ sudo apparmor_parser --purge-cacheAdditionally, to absolutely make sure this AA profile makes it into kernelspace, a reboot is advised instead of restarting the apparmor.service. Fingers crossed! |
|
Absolutely. Like two sides of a coin. Do it in your desktop environment via shell configuration like you mentioned (per-user) or (system-wide) via
That's a wise decision. But be/stay aware of the implications. Wireshark for example will 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 |
Will try to Reboot at some Point ... |
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). |
kmk3
changed the title
|
Tengo lo mismo problema con el flatpak. |
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/programThe text was updated successfully, but these errors were encountered: