-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't break sandbox #19
Comments
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).
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.
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. 😉
@purejava any idea why this is included? |
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.
Yes, it is possible to get access to whole directories instead of files and to keep that access with (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) |
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:
|
No, it was included from the very first version of the manifest.
I had to look up this one. It's interfaces are described here: permission to talk to I haven't checked the Cryptomator code base, if currently any commands are run on the host. |
I then assume it is required to call
|
@SailReal is right. The setting is needed. I installed Cryptomator from Flathub and revoked the setting with: 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 |
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). |
I am not that confident that a JavaFX app can use 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 Implementing all the D-Bus calls yourself would require packaging-specific upstream changes, what we don't want. |
Done in 9aa5a94.
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. |
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.The text was updated successfully, but these errors were encountered: