Firejail: KDE Plasma 5.16: file pickers and Dolphin require access to ${HOME}/.config/kioslaverc

[ayhc]

Running Fedora 30 (with Plasma 5.16 from a third-party repo) and Firejail 0.9.60.

Actual behaviour: Opening Dolphin, or opening the file picker in LibreOffice, results in an error message saying that ${HOME}/.config/kioslaverc cannot be accessed.

Expected behaviour: No error message

Workaround: Manually add the following to the Dolphin and LibreOffice profiles:

noblacklist ${HOME}/.config/kioslaverc

[smitsohu]

Can you please check if, instead of noblacklisting, read-write ${HOME}/.config/kioslaverc resolves the issue as well? And is there something broken or you just see a warning?

[ayhc]

read-write ${HOME}/.config/kioslaverc did not solve the problem.

I did not see any breakage other than the warning message.

[h0tw4t3r]

I am using Plasma with Dolphin, but on the ParrotOS and haven't met this issue.

[smitsohu]

smitsohu@smitsohu:/etc/firejail> grep -r kioslaverc
disable-common.inc:read-only ${HOME}/.config/kioslaverc
disable-common.inc:read-only ${HOME}/.kde/share/config/kioslaverc
disable-common.inc:read-only ${HOME}/.kde4/share/config/kioslaverc
whitelist-common.inc:whitelist ${HOME}/.config/kioslaverc
whitelist-common.inc:whitelist ${HOME}/.kde/share/config/kioslaverc
whitelist-common.inc:whitelist ${HOME}/.kde4/share/config/kioslaverc

Firejail doesn't blacklist this file in the default configuration, did you maybe add this command somewhere?

[ayhc]

Haven't added kioslaverc to any blacklists - ran grep -r kioslaverc in /etc/firejail and got this:

$ grep -r kioslaverc
whitelist-common.inc:whitelist ${HOME}/.config/kioslaverc
whitelist-common.inc:whitelist ${HOME}/.kde/share/config/kioslaverc
whitelist-common.inc:whitelist ${HOME}/.kde4/share/config/kioslaverc
dolphin.local:# Get rid of "~/.config/kioslaverc not writable" error message
dolphin.local:noblacklist ${HOME}/.config/kioslaverc
disable-common.inc:read-only ${HOME}/.config/kioslaverc
disable-common.inc:read-only ${HOME}/.kde/share/config/kioslaverc
disable-common.inc:read-only ${HOME}/.kde4/share/config/kioslaverc
libreoffice.local:# Get rid of "~/.config/kioslaverc not writable" error message
libreoffice.local:noblacklist ${HOME}/.config/kioslaverc

(I added libreoffice.local and dolphin.local as a workaround, as discussed above)

[rusty-snake]

@ayhc just to be complete, you also didn't add it under ~/.config/firejail?

[ayhc]

@rusty-snake can confirm that ~/.config/firejail is empty.

[rusty-snake]

I think you are not using firejail compiled from git, so #1235 would be the answer why noblacklist works even there is no blacklist.

[rusty-snake]

@ayhc try ignore read-only ${HOME}/.config/kioslaverc

[rusty-snake]

may related to #2480.

[ayhc]

@rusty-snake ignore read-only ${HOME}/.config/kioslaverc works.

[rusty-snake]

I played a little bit and think I found the issue.

$ grep 'read-only ${HOME}/.bashrc' /etc/firejail/*.inc
/etc/firejail/disable-common.inc:read-only ${HOME}/.bashrc
$ firejail touch .bashrc
Read-only file system
$ firejail --read-write=~/.bashrc touch .bashrc
Read-only file system
$ firejail --ignore='read-only ${HOME}/.bashrc' touch .bashrc
works
$ firejail --read-write='${HOME}/.bashrc' --profile=/etc/firejail/disable-common.inc  touch .bashrc
Read-only file system
$ firejail --profile=/etc/firejail/disable-common.inc --read-write='${HOME}/.bashrc' touch .bashrc
works

Where do you add the read-write? The read-write must parsed after the read-only.
=> To add read-write to .local (or as an command line argument) files doesn't work, it must be added after include disable-common.inc.

@ayhc, can you confirm that the following also work:

cp /etc/firejail/PROFILE ~/.config/firejail/PROFILE
echo "read-write ${HOME}/.config/kioslaverc" >> ~/.config/firejail/PROFILE

[smitsohu]

On another note, I find it quite surprising that a file picker asks for write access to kioslaverc.

If there are no problems with functionality, it should be ok to just ignore this warning.

[Vincent43]

Is kioslaverc security sensitive file?

[smitsohu]

Is kioslaverc security sensitive file?

I think so, KDE apps go there to check if a proxy server should be used.

On yet another note, should Gnome's dconf database be read-only as well?

[glitsj16]

@smitsohu

On yet another note, should Gnome's dconf database be read-only as well?

${HOME}/.config/dconf is in whitelist-common.inc. Making it read-only would cripple user config changes for GNOME apps. We already have a great override mechanism with the *.local files, so if it is made read-only the worst-case scenario is that people who like it will have to override. We could safely make it read-only for profiles that don't need the GNOME-specific functionality (e.g. KDE apps, daemons), but for those we can just as well blacklist it alltogether IMHO.

[smitsohu]

But iirc all writes to the database are via D-Bus. This would mean dconf writes escape the sandbox as long as there is no nodbus option.

In my fantasy (I cannot try it out in this moment) only the daemon would need a ignore read-only ${HOME}/.config/dconf.

[glitsj16]

@smitsohu You're correct. As far as I know all dconf access relies on D-Bus, I don't see GNOME changing that any time soon. Only now that you pointed out explicitly that without nodbus all profiles writing to dconf are inherently insecure I get where you're going with this. That does indeed change things rather dramatically. We should test your fantasy and act accordingly :+:.

[rusty-snake]

Use xdg-dbus-proxy https://github.com/netblue30/firejail/issues/2683#issuecomment-491023735 or netns-exec https://github.com/netblue30/firejail/issues/2683#issuecomment-495919268.

On restricting dbus sandbox escape we can do more.

[smitsohu]

without nodbus all profiles writing to dconf are inherently insecure

Possibly an attacker doesn't even need to use the D-Bus interface. If I understand it right this is just a convention, thought to reduce the risk of database corruption.

The database is user writable, a malicious process can (possibly) go to the file directly. If that is the case, it would be useful to mount it read-only (especially as it is exposed through whitelist-common.inc).

[rusty-snake]

@ayhc
I'm closing here due to inactivity, please fell free to reopen if you still have this issue.