Limit the filesystem to selected xdg portals

[yookoala]

• Improve sandbox security by change the "--filesystem" flag from
  "home" to "xdg-download". This means Signal can only access the
  XDG Download folder of the user instead of full access to home
  folder.

• Resolve Filesystem access scope #153.

[flathubbot]

Started test build 29472

[yookoala]

Tested on my computer and found no issue.

[flathubbot]

Build 29472 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/28387/org.signal.Signal.flatpakref

[yookoala]

Please help labeling this PR with the hacktoberfest-accepted tag. Thanks.

[bermeitinger-b]

What happens if I want to share an image with a contact? Without access to Home->Pictures, this will not be possible, right?

[yookoala]

I think the advantage of a sandbox application package (e.g. Flatpak) in the first place is to limit the security access of the packaged application. Allowing application to access the whole user home directory is quite an overkill if you simply want users to be able to share files from "Home > Picture".

The documentations said you can specify --filesystem multiple times in flatpak build. According to the Filesystem Permission reference page, here are the acceptable values:

host	Access all files [3]
home	Access the home directory
/some/dir	Access an arbitrary path
~/some/dir	Access an arbitrary path relative to the home directory
xdg-desktop	Access the XDG desktop directory
xdg-documents	Access the XDG documents directory
xdg-download	Access the XDG download directory
xdg-music	Access the XDG music directory
xdg-pictures	Access the XDG pictures directory
xdg-public-share	Access the XDG public directory
xdg-videos	Access the XDG videos directory
xdg-templates	Access the XDG templates directory
xdg-config	Access the XDG config directory
xdg-cache	Access the XDG cache directory
xdg-data	Access the XDG data directory
xdg-run/path	Access subdirectories of the XDG runtime directory (where path is any subdirectory)

I'd propose to include all the common user file folders: xdg-desktop, xdg-documents, xdg-download, xdg-music, xdg-pictures, xdg-public-share, xdg-videos. That way other files in the root (especially vital directories like: .ssh, .config) are not exposed to the supposedly sandboxed application while still provide sufficient flexibility for file sharing.

[bermeitinger-b]

Adding all these directories might make sense. But if a user wants to send a file from another location which is not handled by xdg?
I don't think security should be preferred over usability in this case.

Does is say that this application is "supposedly sandboxed" in regard to file access?

[yookoala]

Adding all these directories might make sense. But if a user wants to send a file from another location which is not handled by xdg?
I don't think security should be preferred over usability in this case.

Does is say that this application is "supposedly sandboxed" in regard to file access?

There is always a struggle between usability and security. Usability is not always the priority, nor does security. Frankly, any filesystem access to an application imposes a security / privacy threat. The question is "what is the right balance for the specific application".

I think if a user want to share any files from folder other than "Document", "Downloads", "Pictures", "Videos", "Music" and "Desktop" folder, it is always easy to copy or move the file(s) there before sharing. On the other hand, no user would want to compromise their SSH keys, security configs, VPN password because they simply wants to share files from other folder. I don't think that is the right balance.

If usability is always the priority, why don't we simply give the application a "/" scope? There is always a possibility that I need to share my /etc/passwd or /etc/resolve.conf through a instant messenger application, right? Further, why sandbox the application in the first place?

I think one of the main point to package an application with flatpak is to have every application's access to the OS limited. The applications permissions are limited so when it is compromised, no severe harm would come to the system, or the user's sensitive data. At least that's what it speaks to people when they labelled themselves "Sandboxed":

[bermeitinger-b]

Thank your for your lengthy description, you made a good point.

I never saw this "Sandboxed" description and I wonder what it even means for this application with full home and network access.

If you propose a PR, I'll approve of it when the aforementioned xdg portals are included, especially pictures, videos, and maybe documents.

[flathubbot]

Started test build 29962

[flathubbot]

Build 29962 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/28853/org.signal.Signal.flatpakref

[bermeitinger-b]

Thank you very much.

[genodeftest]

Many thanks!

[Maltimore]

I think something must've gone wrong: I can no longer send files from any of the above-mentioned directories, however I can still send the /etc/passwd file.
I'm on KDE neon 20.04 with flatpak 1.6.5.

[bermeitinger-b]

I can partially verify this, however, did you look at the sent passwd file? It is the one from the sandboxed environment and not the host system.

[Maltimore]

Oh, right. Sorry!
This leaves the issue that I can not send any documents that are in the allowed folders (see above). Shall I open a separate issue for that?

[yookoala]

I think something must've gone wrong: I can no longer send files from any of the above-mentioned directories, however I can still send the /etc/passwd file.
I'm on KDE neon 20.04 with flatpak 1.6.5.

Can you show us a screenshot of the filesystem browser in your send file process?

[Maltimore]

Sure, here it is. There's not much to see though. "tubcloud" is my nextcloud folder, but neither of the two bookmarks labeled "tubcloud" are clickable, and neither is the "Desktop" one. "Other Locations" brings me to the root folder, with folders like etc, sys, bin etc. But these files are from the flatpak filesystem, as you pointed out above.

[bermeitinger-b]

Have you, by any chance, overwritten the sandbox values at some point?

[Maltimore]

No, I haven't messed with my flatpak install in any way.

[yookoala]

@Maltimore I tried to reproduce the issue but can't.

I started a new VM with QEMU and installed a flash copy of Kubuntu 20.04.1. Then I installed flatpak with apt. And installed Signal Desktop by clicking the "Install" button on the Flathub page.

Here is what I got when I click "+" in a chat:

To be sure, I created an empty test.txt in the user's Download folder. Then I tried to access it in the dialog. It appears normally:

This looks to be a configuration issue.

@Maltimore, is there anything I could have done differently to mimic your environment and reproduce the issue?

Environment

$ flatpak --version
Flatpak 1.6.5

$ flatpak list
Name                          Application ID                              Version         Branch         Origin                Installation
Freedesktop Platform          org.freedesktop.Platform                    20.08.0         20.08          flathub               system
default                       org.freedesktop.Platform.GL.default                         20.08          flathub               system
openh264                      org.freedesktop.Platform.openh264           2.1.0           2.0            flathub               system
Breeze Gtk theme              org.gtk.Gtk3theme.Breeze                                    3.22           flathub               system
Signal Desktop                org.signal.Signal                           1.37.2          stable         signal-origin         system

$ flatpak info --show-permissions org.signal.Signal
[Context]
shared=network;ipc;
sockets=x11;pulseaudio;
devices=all;
filesystems=xdg-documents;xdg-desktop;xdg-music;xdg-download;xdg-pictures;xdg-videos;xdg-public-share;

[Session Bus Policy]
org.kde.StatusNotifierWatcher=talk
org.freedesktop.Notifications=talk
org.kde.StatusNotifierItem-2-1=own

[yookoala]

@Maltimore: This is another attempt to reproduce the issue. Installed a KDE Neon 5.20.2 / 20.04 from their User Edition disc image (with flatpak already installed) in Chinese locale (i.e. default ~/.config/user-dirs.dirs setup with the locale) in a QEMU VM. Again, the Signal Desktop was installed by clicking the "Install" button on the Flathub page. Also have a custom test.txt created in the download folder:

The Chinese folder names read:

• 圖片 (Pictures)
• 下載 (Downloads)
• 桌面 (Desktop)
• 影片 (Videos)
• 音樂 (Musics)
• 文件 (Documents)
• 分享 (Shared)

Seems totally normal.

P.S. I've also created a file in the / folder of the system. The flatpak Signal Desktop, as expected, cannot access the real / directory and instead got a sandboxed version only.

Environment

$ flatpak --version
Flatpak 1.6.5

$ flatpak list
Name                          Application ID                               Version          Branch         Installation
Freedesktop Platform          org.freedesktop.Platform                     20.08.0          20.08          system
default                       org.freedesktop.Platform.GL.default                           20.08          system
openh264                      org.freedesktop.Platform.openh264            2.1.0            2.0            system
Breeze Gtk theme              org.gtk.Gtk3theme.Breeze                                      3.22           system
Signal Desktop                org.signal.Signal                            1.37.2           stable         system

$ flatpak info --show-permissions org.signal.Signal 
[Context]
shared=network;ipc;
sockets=x11;pulseaudio;
devices=all;
filesystems=xdg-documents;xdg-desktop;xdg-music;xdg-download;xdg-pictures;xdg-videos;xdg-public-share;

[Session Bus Policy]
org.kde.StatusNotifierWatcher=talk
org.freedesktop.Notifications=talk
org.kde.StatusNotifierItem-2-1=own

[Maltimore]

Hi @yookoala
I am very sorry for not responding. Thank you very, very much for putting in all the effort to reproduce this issue.
Your reproduction of my environment seems perfect. I have no idea why, with the same setup, I can not access any files. But it seems likely that the issue is on my end then. I will ask for the corresponding github issue to be closed.
Thanks again for your effort.