Can't open chromium unless ignore include whitelist-runuser-common.inc (hyprland)

Question

Can't open chromium unless ignore include whitelist-runuser-common.inc (hyprland)

variasdesign opened this issue 3 months ago · comments

Description

Hello. I'm trying to troubleshoot why Chromium was crashing with no apparent reason. Since launching chrome from the terminal didn't print any errors, I started trying ignore directives in my chromium-common.local, I arrived to ignore include whitelist-runuser-common.inc, which lets Chromium open normally.

What exactly happens in whitelist-runuser-common.inc? When ignoring it, I get a bunch of errors Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied, but otherwise I can open chromium. Thanks for any help.

Steps to Reproduce

Steps to reproduce the behavior

Run in bash LC_ALL=C firejail chromium (LC_ALL=C to get a consistent
output in English that can be understood by everybody)
Chromium immediately crashes without apparent error, only firejail cleanup mesages.

Expected behavior

Chromium opens

Actual behavior

Chromium crashes

Behavior without a profile

Opens without problems

Additional context

Also running AppArmor. Fresh Arch install running Hyprland.

Environment

Arch Linux
Firejail 0.9.72

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program

LC_ALL=C firejail chromium
Reading profile /etc/firejail/chromium.profile
Reading profile /etc/firejail/chromium-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-xdg.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Parent pid 43126, child pid 43127
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Warning: cannot create chromium directory
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Child process initialized in 142.39 ms
Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.

Parent is shutting down, bye...

Output of LC_ALL=C firejail --debug /path/to/program

glitsj16 · Answer 1 · Tue Feb 27 2024 20:52:59 GMT+0800 (China Standard Time)

Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features

FYI: be careful when running firejail like this. The above warning shows you used firecfg, which placed a symlink in /usr/local/bin/chromium pointing to /usr/bin/firejail for easy desktop integration. Try to avoid this doubled sandboxing by making a habit out of using firejail /full/path/to/executable instead.

variasdesign · Answer 2 · Tue Feb 27 2024 20:56:23 GMT+0800 (China Standard Time)

Whoops, sorry about that. I usually run the applications by their symlink, I just blindly copypasted the troubleshoot commands. The problem persists, though. Thanks for the heads-up.

glitsj16 · Answer 3 · Mon Apr 15 2024 19:19:04 GMT+0800 (China Standard Time)

Also running AppArmor. Fresh Arch install running Hyprland.

whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like Hyprland needs additional path(s) whitelisted. Can you determine what paths it creates in /run/user/$UID?

variasdesign · Answer 4 · Mon Apr 15 2024 23:20:42 GMT+0800 (China Standard Time)

Also running AppArmor. Fresh Arch install running Hyprland.

whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like Hyprland needs additional path(s) whitelisted. Can you determine what paths it creates in /run/user/$UID?

I'm not really sure, but it seems it doesn't create anything inside /run/user/$UID. Here is my /run/user/$UID:

drwx------ - varias 15 abr 17:15 .
drwxr-xr-x - root   15 abr 17:09 ..
drwx------ - varias 15 abr 17:09 at-spi
drwx------ - varias 15 abr 17:09 dconf
dr-x------ - varias  1 ene  1970 doc
drwx------ - varias 15 abr 17:09 gcr
drwx------ - varias 15 abr 17:09 gnupg
drwxr-xr-x - varias 15 abr 17:09 p11-kit
drwxr-x--- - varias 15 abr 17:09 polychromatic
drwxr-xr-x - varias 15 abr 17:09 psd
drwx------ - varias 15 abr 17:09 pulse
drwxr-x--- - varias 15 abr 17:09 systemd
srwxr-x--- - varias 15 abr 17:09 Alacritty-wayland-1-2134.sock
srwxr-x--- - varias 15 abr 17:10 Alacritty-wayland-1-3909.sock
srwxr-x--- - varias 15 abr 17:12 Alacritty-wayland-1-5906.sock
srw-rw-rw- - varias 15 abr 17:09 bus
srwxr-x--- - varias 15 abr 17:09 fnott-wayland-1.sock
.rw-r----- 4 varias 15 abr 17:09 openrazer-daemon.pid
.rw-r----- 0 root   15 abr 17:15 pam-u2f-authpending
srw-rw-rw- - varias 15 abr 17:09 pipewire-0
srw-rw-rw- - varias 15 abr 17:09 pipewire-0-manager
.rw-r----- 0 varias 15 abr 17:09 pipewire-0-manager.lock
.rw-r----- 0 varias 15 abr 17:09 pipewire-0.lock
.rw-r----- 0 varias 15 abr 17:09 psd.pid
srw------- - varias 15 abr 17:09 ssh-agent.socket
srwxr-x--- - varias 15 abr 17:09 swww.socket
.rw------- 0 varias 15 abr 17:10 tofi.lock
srwxr-x--- - varias 15 abr 17:09 wayland-1
.rw-r----- 0 varias 15 abr 17:09 wayland-1.lock

It does, however, create a session directory inside /tmp/hypr:

drwxrwxrwt  - varias 15 abr 17:09 .
drwxrwxrwt  - root   15 abr 17:10 ..
drwxrwx---  - varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781
.rw-r----- 15 varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781.lock

Containing two sockets and a log.

Thanks for your help.

glitsj16 · Answer 5 · Mon Apr 15 2024 23:56:20 GMT+0800 (China Standard Time)

@variasdesign
Thanks for the /run/user/$UID output. Not sure (yet) why it works when you ignore including whitelist-runuser-common.inc (wruc), this is my first encounter with hyprland. As you've noticed, we have zero support for Hyprland in Firejail currently, so until that changes you'll need to keep 'wruc' out of the chromium profiles. There might be other apps that need similar treatment.

Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that /usr/share/hyprland contains its configuration defaults, besides per-user ~/.config/hypr. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland...

variasdesign · Answer 6 · Tue Apr 16 2024 00:25:09 GMT+0800 (China Standard Time)

Thanks for the pointers. Poking around /run/user/$UID, I noticed the psd directory, which is created by profile-sync-daemon. The daemon mounts a tmpfs directory to speed up browser performance. I just needed to whitelist ${RUNUSER}/psd and it works now. I didn't notice until now because Firefox, which is my main browser, apparently works without any problems whatsoever without whitelisting psd.

Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that /usr/share/hyprland contains its configuration defaults, besides per-user ~/.config/hypr. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland...

How would I go about protecting those paths? Thank you.

glitsj16 · Answer 7 · Tue Apr 16 2024 00:50:47 GMT+0800 (China Standard Time)

How would I go about protecting those paths?

Most of the profiles include globals.local to offer users a way to override options. So in this context you can blacklist the relevant paths in such a file:

$ cat ~/.config/firejail/globals.local
# Firejail :: persistent global definitions

# protect hyprland configuration
blacklist ${HOME}/.config/hypr
blacklist /usr/share/hyprland

That should keep these inaccessible in sandboxes.

variasdesign · Answer 8 · Tue Apr 16 2024 01:02:32 GMT+0800 (China Standard Time)

Thanks for the help. I've just applied the aforementioned config. Conversely, do you think I should blacklist the /tmp/hypr directory too? I don't have use for the sockets, at least for now.

glitsj16 · Answer 9 · Tue Apr 16 2024 01:15:17 GMT+0800 (China Standard Time)

Very welcome. I didn't want to suggest blacklisting those hyprland sockets because I don't know how that will affect Hyprland. But if you don't experience any negative effects doing so, sure, you can add that to the globals.local too. In case something breaks, there's always the option of adding the counterpart noblacklist /tmp/hypr to another foo.local. This replicates the way Firejail internally works, on a per-user basis under ~/.config/firejail and system-wide under /etc/firejail.

HTH