don't break sandbox

[alexmo1997]

Currently, this package uses --filesystem=home which breaks the flatpak sandbox completely.
You should use the appropriate locations in ~/.var/app/org.cryptomator.Cryptomator/ (where the XDG locations are inside flatpaks, you hardcoded it to ~/.config, ~/.local/share, etc).

Especially a security focused application like cryptomator should set a good example by not disabling security features unnecessarily.

Ideally, for the selection of where to put the vault, cryptomator should use org.freedesktop.portal.FileChooser. However, I think that would have to be done upstream.

Another issue is --talk-name=org.freedesktop.Flatpak which basically allows arbitrary access to the host system.

[overheadhunter]

Currently, this package uses --filesystem=home which breaks the flatpak sandbox completely.

You are aware that other than e.g. a word processor, Cryptomator does not only work on individual documents that you explicitly opened via a file chooser but needs to access file structures that users defined in previous launches? Do you know of some way to make the sandbox remember previously chosen locations?

Some users even argue that restricting to the home dir is too strict, as this prevents them from accessing vaults located elsewhere (see #16).

You should use the appropriate locations in ~/.var/app/org.cryptomator.Cryptomator/ (where the XDG locations are inside flatpaks, you hardcoded it to ~/.config, ~/.local/share, etc).

The locations are in fact not hardcoded but read from the environment, so every distribution can change it. We can easily tell the Flatpak bundle to use some other storage location for preferences.

Especially a security focused application like cryptomator should set a good example by not disabling security features unnecessarily.

First of all, and I really don't like repeating this all the time, Cryptomator has a certain well-defined security target, which is protecting files in the cloud. Cryptomator is not about protecting you from threats on your local machine.

The whole purpose of a sandbox is not to "deny all", but to "deny by default" and then only allow the minimal required permission for a certain use case. If you consider this "breaking" something, you may have a different understanding of this concept.

Last, let me point you to this issue, where we discussed the Flatpak package for a long time, including several comments over a three year period regarding the sandbox. Cryptomator is doing some things that go beyond normal "document based" apps and we have almost given up on Flatpak. So if you don't like "breaking the sandbox", use the AppImage which doesn't have any sandbox to break. 😉

Another issue is --talk-name=org.freedesktop.Flatpak which basically allows arbitrary access to the host system.

@purejava any idea why this is included?

[alexmo1997]

First of all, and I really don't like repeating this all the time, Cryptomator has a certain well-defined security target, which is protecting files in the cloud. Cryptomator is not about protecting you from threats on your local machine.

I'm sorry, I didn't mean to offend, I just think that flatpak sandboxing is important; of course this doesn't mean that cryptomator is somehow insecure.

You are aware that other than e.g. a word processor, Cryptomator does not only work on individual documents that you explicitly opened via a file chooser but needs to access file structures that users defined in previous launches? Do you know of some way to make the sandbox remember previously chosen locations?

Yes, it is possible to get access to whole directories instead of files and to keep that access with org.freedesktop.portal.Documents, which I think is exactly what cryptomator would need. Furthermore, I think this could help with the problem of home dir being to strict, as this would handle files everywhere equally. If I am wrong, please correct me.

(see https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Documents and https://github.com/flatpak/xdg-desktop-portal/wiki/The-Permission-Store)

[overheadhunter]

Yes, it is possible to get access to whole directories instead of files and to keep that access with org.freedesktop.portal.Documents, which I think is exactly what cryptomator would need.

In that case it is worth investigating. But first we need to check what API JavaFX uses under the hood for its file picker dialog.

Furthermore we have two more sources for vault paths:

1. drag-and-dropping vaults to the vault list
2. passing a path as a command line argument during start

[purejava]

Another issue is --talk-name=org.freedesktop.Flatpak which basically allows arbitrary access to the host system.

@purejava any idea why this is included?

No, it was included from the very first version of the manifest.

--talk-name args in general allow access to D-Bus objects.

I had to look up this one. It's interfaces are described here: permission to talk to org.freedesktop.Flatpak means, that an app can run any command on the host and bypasses the sandbox completely.

I haven't checked the Cryptomator code base, if currently any commands are run on the host.

[SailReal]

It's interfaces are described here: permission to talk to org.freedesktop.Flatpak means, that an app can run any command on the host and bypasses the sandbox completely.

I then assume it is required to call fusermount on the host machine

org.cryptomator.Cryptomator/build-aux/fusermount-wrapper.sh

Line 15 in dc567fb

exec flatpak-spawn --host --forward-fd=1 --forward-fd=2 $FD_ARGS fusermount "$@"

[purejava]

@SailReal is right. The setting is needed. I installed Cryptomator from Flathub and revoked the setting with: flatpak override --no-talk-name=org.freedesktop.Flatpak.

FUSE-mounting then fails with:

Portal call failed: org.freedesktop.DBus.Error.ServiceUnknown
07:32:47.293 [fuseMount-0-main] INFO  org.cryptomator.common.vaults.Vault - Unmounted vault 'Test'
07:32:47.294 [fuseMount-0-main] WARN  org.cryptomator.common.vaults.Vault - Unexpected unmount and lock of vault Test
ru.serce.jnrfuse.FuseException: Unable to mount FS
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:293)
	at org.cryptomator.frontend.fuse@1.3.4/org.cryptomator.frontend.fuse.mount.AbstractMounter.lambda$mount$0(AbstractMounter.java:26)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:289)
	... 2 common frames omitted
07:32:57.255 [JavaFX Application Thread] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'Test' failed.
07:32:57.255 [JavaFX Application Thread] ERROR o.c.ui.unlock.UnlockWorkflow - Unlock failed for technical reasons.
org.cryptomator.common.vaults.Volume$VolumeException: Unable to mount Filesystem
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.FuseVolume.mount(FuseVolume.java:55)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.FuseVolume.mount(FuseVolume.java:42)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.Vault.unlock(Vault.java:154)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.keyloading.KeyLoadingStrategy.use(KeyLoadingStrategy.java:79)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.attemptUnlock(UnlockWorkflow.java:72)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:62)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:35)
	at javafx.graphics@19/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.cryptomator.frontend.fuse.mount.FuseMountException: ru.serce.jnrfuse.FuseException: Unable to mount FS
	at org.cryptomator.frontend.fuse@1.3.4/org.cryptomator.frontend.fuse.mount.AbstractMounter.mount(AbstractMounter.java:46)
	at org.cryptomator.frontend.fuse@1.3.4/org.cryptomator.frontend.fuse.mount.Mounter.mount(Mounter.java:15)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.FuseVolume.mount(FuseVolume.java:53)
	... 12 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:293)
	at org.cryptomator.frontend.fuse@1.3.4/org.cryptomator.frontend.fuse.mount.AbstractMounter.lambda$mount$0(AbstractMounter.java:26)
	... 1 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:289)
	... 2 common frames omitted

[overheadhunter]

Thanks for verifying, I guess we should add comments to each of the sandbox configurations.

Cryptomator just isn't Paint. I would suggest to close this issue as invalid and open a more specific one, if there is a suggestion on how to make use of different file system permissions (that can be implemented without requiring packaging-specific upstream changes).

[purejava]

Yes, it is possible to get access to whole directories instead of files and to keep that access with org.freedesktop.portal.Documents, which I think is exactly what cryptomator would need. Furthermore, I think this could help with the problem of home dir being to strict, as this would handle files everywhere equally. If I am wrong, please correct me.

(see https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Documents and https://github.com/flatpak/xdg-desktop-portal/wiki/The-Permission-Store)

I am not that confident that a JavaFX app can use org.freedesktop.portal.Documents easily.

As far as I understand the concept of Flatpak's desktop portals and from what I read here and here, you can either implement all the D-Bus calls yourself to handle files and directories or your environment uses the portals implicitly, like GTK does, but JavaFX doesn't, as it does not provide implementations of the org.freedesktop.impl.portal.* interfaces.

Implementing all the D-Bus calls yourself would require packaging-specific upstream changes, what we don't want.

[infeo]

we should add comments to each of the sandbox configurations

Done in 9aa5a94.

Cryptomator just isn't Paint.

True. And regarding FUSE, it even got worse 😅 To get the latest FUSE-updates working with Cryptomator, i had to allow access to all devices. Therefore, people need to be more specific about what sandbox permission can be improved.