mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4280] Blacklisting directories of encrypted containers #2607
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#2607
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 @MrFrank17 on GitHub (May 14, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4280
Hi all,
I am using Cryptomator and KDE's vault and mount the unencrypted container to
~/Vault/dir1,~/Vault/dir2,...In
globals.localthese directories are blacklisted and only some programs get access by noblacklisting them in their local profiles. These works as expected until I mount the encrypted container: then other program can access these directories even without noblacklisting. I am using Kubuntu 21.04.Thanks
Frank
@rusty-snake commented on GitHub (May 17, 2021):
How exactly did you the blacklist?
@MrFrank17 commented on GitHub (May 17, 2021):
Hi rusty-snake,
meanwhile I renamed
globals.localtodisable-common.local. It looks like that:blacklist ${HOME}/Vaults/Schlüsselblacklist ${HOME}/Vaults/Backupblacklist ${HOME}/Vaults/VeraCrypt# blacklist ${HOME}/Vaults/DokumenteOn startup cryptomator opens a vault automatically and mounts it to
Backup, therefore this folder is always accessible. Interestingly, if I open a shell and start a firejailed program from that folder it tells me something like that:frank@frank-laptop:~/Vaults/Backup$ okularReading profile /etc/firejail/okular.profileError: cannot access profile file: okular.localIf I start okular, I can browse to
Backupand see the content (even if I do not have aokular.localto do anoblacklistingofBackup).Once I open the KDE vault, which mounts to
Schlüssel, it shows the same behavior.Cheers
Frank
@rusty-snake commented on GitHub (May 17, 2021):
Does
firejail ls -l ~/Vaultsshow the dirs blacklisted (e..g d--------- root root)? If so doesfirejail --dbus-user=none okularstill have access to these files?Sounds like #3798
@MrFrank17 commented on GitHub (May 17, 2021):
That's the output:
drwxrwxrwx 1 frank frank 4096 Feb 18 18:32 Backupdrwxrwxr-x 2 frank frank 4096 Feb 19 11:21 Dokumentedr-------- 2 nobody nogroup 40 Mai 17 19:05 Schlüsseldr-------- 2 nobody nogroup 40 Mai 17 19:05 VeraCryptfirejail --dbus-user=none okulardoes not make a difference.In the linked issue it was mentioned that fuse mounts do not really work together with firejail. Is that the reason?
@rusty-snake commented on GitHub (May 17, 2021):
Maybe. IDK how Cryptomator and KDE Vaults work.
From your OP I saw there possible causes:
Portals can not work with
--dbus-user=none. KIO either uses D-Bus too or has it's own socket IDK. Mounts should not make any differences between ls and okular. You ls output shows they are blacklisted. Need to rethink this.@MrFrank17 commented on GitHub (May 17, 2021):
I checked Cryptomator: it mounts via fuse in my setup. Not sure about KDE vault though.
About my ls output: yes, the locked containers show that they are blacklisted. Once I unlock them (like Backup)m they are no longer blacklisted. So ls and okular show the same behavior. Or I misunderstood you ...
@MrFrank17 commented on GitHub (May 18, 2021):
Quick update: I added the fuse handling as described here: https://firejail.wordpress.com/documentation-2/basic-usage/?like_comment=579#encfs
Cryptomator now works as expected. Now I need to figure out how to do the same withe KDE vault, but I guess this is not a firejail issue anymore ...
@MrFrank17 commented on GitHub (May 21, 2021):
Two more observations: maybe they are related to that issue, maybe not. And maybe some can comment :-)
The file dialog of firefox shows the blacklisted entries, which are now successfully blocked, several times (see screenshot)
Is this happening due to firejail? If yes, how to get rid of all the duplicates? As they are blacklisted, they shouldn't appear in the first place...
Within Cryptomator I have the option to open a filebrowser pointing to the vault, in my case KDEs dolphin. When I want to open a document through that filebrowser by double clicking, the associated program opens and immediately closes again. If I open the same program separately, I can browse to the same folder and successfully open that file. If I open dolphin separately, not via Cryptomator, file opening works. Neither Cryptomator nor dolphin are firefailed - could it still be that firejail interferes here?
Thanks
@rusty-snake commented on GitHub (May 21, 2021):
/etc/fstabis accessible inside the sandbox (https://github.com/netblue30/firejail/issues/2406#issuecomment-528281301). https://github.com/netblue30/firejail/issues/2406#issuecomment-528281301 shows workarounds.firejail --treenot show it?@MrFrank17 commented on GitHub (May 21, 2021):
This is already an improvement, but still some (but less) duplicates. I also tried the
x-gvfs-hidemount options, but Cryptomator does not like it. Anyway, I can live thatI removed dolphin from
/usr/lib/x86_64-linux-gnu/firejail/firecfg.configso I can open files from dolphin without having the associated programs running under the dolphin profile.@rusty-snake commented on GitHub (Aug 4, 2021):
FYI
12d1de4845 (diff-af35b8a6ad30ea07f24afd1e685ff48567dd39b5ba7df80af8c601408290ffe3)Do you still need help somewhere or can we close?