Please provide way to not use portals, or enforce permissions on portals

[BillDietrich]

Linux distribution and version

Ubuntu MATE 20.04

Flatpak version

1.6.5

Description of the problem

IMO Flatpak's permissions/portals system is confusing, non-standard, and not what many users want. User action in a "portal" is deemed to grant permission that overrides the permissions set outside the image (via CLI or Flatseal). But as a desktop user/admin, I don't care whether an attempted access by an app was stimulated by user action or some other way. The permissions I set outside the app should control that app, period, no exceptions.

For example, I want to say "Firefox can access only these 4 directories, period. I don't care what caused the access from Firefox, whether the user asked for it in a dialog or not, Firefox always can access only these 4 directories."

Please add some setting in the permission UI (CLI and/or Flatseal) to say "these permissions apply to the WHOLE app: portals, file chooser dialogs, user actions, internal app code, everything". The current situation would be covered by leaving that setting off, and what I want would be covered by turning it on. Thanks.

[Arxcis]

Hi @BillDietrich. I think what you are actually asking for, is a way to disable a specific portal when running an app. This should be possible in Flatpak today (Update: not possible today. See comment below).

Example of disabling org.freedesktop.portal.FileChooser:

flatpak run --no-talk-name="org.freedesktop.potal.FileChooser" org.mozilla.firefox

This would solve your problem, wouldn't it? This way, you could configure 4 directories available to org.mozilla.firefox by default, and since the FileChooser-portal is disabled, the filesystem-permissions would never change.

[Arxcis]

Update/Bug-report

Actually, I tried running the command above with org.gnome.Epiphany, which only has access to xdg-download-folder, and nothing else by default.

Persmissions:

$ flatpak info org.gnome.Epiphany --show-permissions
[Context]
shared=network;
sockets=wayland;pulseaudio;
devices=dri;
filesystems=xdg-download;/run/.heim_org.h5l.kcm-socket;

[System Bus Policy]
org.freedesktop.GeoClue2=talk

Command:

flatpak run --no-talk-name="org.freedesktop.portal.FileChooser" org.gnome.Epiphany

Expected behaviour

• I expect Epiphany to not have access to the org.freedesktop.portal.FileChooser, and fallback to regular non-portal file-chooser.
• When open the file-chooser, I expect to only see the Download-folder. Here is a screenshot from Firefox displaying expected behaviour:

Actual behaviour (in Epiphany)
All files are still visible, and openable, in the file-chooser, as if I still have access to the portal:

This looks like a bug to me. It seems like Flatpak ignores my --no-talk-name="org.freedesktop.portal.FileChooser"-override.

Versions

$ uname -a && flatpak --version
Linux pop-os 5.8.0-7630-generic #32~1605108806~20.10~7e52b13-Ubuntu SMP Wed Nov 11 19:10:30 UTC  x86_64 x86_64 x86_64 GNU/Linux
Flatpak 1.8.2

$ flatpak info org.gnome.Epiphany

GNOME Web - Web browser for GNOME

          ID: org.gnome.Epiphany
         Ref: app/org.gnome.Epiphany/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 3.38.0

$ flatpak info org.mozilla.firefox

Firefox - Mozilla Firefox Web Browser

          ID: org.mozilla.firefox
         Ref: app/org.mozilla.firefox/x86_64/beta
        Arch: x86_64
      Branch: beta
     Version: 84.0b3

[Arxcis]

Could someone please confirm that this bug is reproducible?

[Arxcis]

The root of the problem?
When I add an override like --no-talk-name, it does not show up when running the flatpak info --show-permissions. It just removes the line if it is already there. This leaves no room to express that you want to turn off something that is by on by default, like portals.

Example:

$ flatpak override --user --talk-name=org.freedesktop.portal.FileChooser org.gnome.Epiphany

$ flatpak info org.gnome.Epiphany --show-permissions
[Context]
shared=network;
sockets=wayland;pulseaudio;
devices=dri;
filesystems=xdg-download;/run/.heim_org.h5l.kcm-socket;

[Session Bus Policy]
org.freedesktop.portal.FileChooser=talk                    <------------ JUST ADDED

[System Bus Policy]
org.freedesktop.GeoClue2=talk

$ flatpak override --user --no-talk-name=org.freedesktop.portal.FileChooser org.gnome.Epiphany

$ flatpak info org.gnome.Epiphany --show-permissions
[Context]
shared=network;
sockets=wayland;pulseaudio;
devices=dri;
filesystems=xdg-download;/run/.heim_org.h5l.kcm-socket;

                                                                   <------------------ REMOVED
[System Bus Policy]
org.freedesktop.GeoClue2=talk

What I really wanted to happen:

$ flatpak override --user --no-talk-name=org.freedesktop.portal.FileChooser org.gnome.Epiphany

$ flatpak info org.gnome.Epiphany --show-permissions
[Context]
shared=network;
sockets=wayland;pulseaudio;
devices=dri;
filesystems=xdg-download;/run/.heim_org.h5l.kcm-socket;

[Session Bus Policy]
org.freedesktop.portal.FileChooser=none                <------------ WHAT I REALLY WANTED

[System Bus Policy]
org.freedesktop.GeoClue2=talk

[Arxcis]

It is really wired that this happens, because the test-override.sh should have caught this bug:

flatpak/tests/test-override.sh

Lines 94 to 103 in b1fdf6c

	${FLATPAK} override --user --own-name=org.foo.Own org.test.Hello
	${FLATPAK} override --user --talk-name=org.foo.Talk org.test.Hello
	${FLATPAK} override --user --talk-name=org.foo.NoTalk org.test.Hello
	${FLATPAK} override --user --no-talk-name=org.foo.NoTalk org.test.Hello
	${FLATPAK} override --user --show org.test.Hello > override
	assert_file_has_content override "^\[Session Bus Policy\]$"
	assert_file_has_content override "^org\.foo\.Own=own$"
	assert_file_has_content override "^org\.foo\.Talk=talk$"
	assert_file_has_content override "^org\.foo\.NoTalk=none$"

NEVERMIND! The test uses a different command which shows the =none fields correctly. If I run the same command as the tests, I also get the missing =none fields.

$ flatpak override --user --show  org.gnome.Epiphany
[Context]
shared=!ipc;
sockets=!x11;!fallback-x11;

[Session Bus Policy]
org.freedesktop.portal.FileChooser=none

Hmm 🤔

Conclusion
I think my conclusion is that currently Flatpak is very much designed to not let you turn off portals. As stated elsewhere ( tchx84/Flatseal#196 (comment)), I think this is by design. It would be cool to hear what @alexlarsson thinks about this issue 🙏

[alexlarsson]

I wouldn't say it was designed to not let you turn off portals. But it wasn't designed to let you turn them off so it accidentally is not possible. Making it possible to be turned off would be fine with me, but its not really a personal priority for me.

[Arxcis]

@alexlarsson Ok, thank you for clarifying. It makes sense to me that it is accidentally not possible 👍 I guess this issue is a feature-request then. Not a high priority for me either, but I can see that it may be useful in certain cases elaborated by OP @BillDietrich. For instance, not allowing portal-access to apps, which should not need portal-access.

[JJRcop]

I'd like to clarify here to @BillDietrich that Flatpak and Flatseal are separate projects with separate developers. The way this would happen is first Flatpak would implement the overrides feature for disabling portals, then only after this could Flatseal expose UI to change the override.

But as stated, these are separate projects, so it is incorrect to refer to them as if they were different components of a single project.

[ssokolow]

I'll also weigh in on the necessity of this as, currently, Kubuntu Linux 20.04 LTS includes a version of xdg-desktop-portal-kde that doesn't support directory pickers (it just shows a file picker that doesn't let you pick anything) and the PPA only offers updates for xdg-desktop-portal-gtk.

Normally, I export GTK_USE_PORTAL=1 to get KDE dialogs in even the non-Flatpak'd applications but, in this case, use of the portal renders the ScummVM Flatpak completely incapable of adding games. (In a moment, I'll be opening a bug report on it asking for them to either find a workaround or forcibly disable use of the portal on their end.)

(The only reason I can play the games I already have in it is because I copied an existing scummvm.ini from the older apt version which supports fewer games.)

If it were possible to disable the portal, then it would Just Work™ because I've manually granted :ro access to the folder where I keep my ScummVM game assets.

[eike-fokken]

I would like to second the feature request here. I like to severely lock down my flatpak-sandboxed apps.

If I, the user, can grant the read permission in the filechooser portal, probably a malicious program can as well, no?

In addition should the lines

[Session Bus Policy]
org.freedesktop.portal.FileChooser=none 

have the effect of disallowing the filechooser dialogue? I thought so but apparently my app can still invoke the filechooser.

Is there any other, however hackish way to disallow the use of the filechooser?

[rusty-snake]

probably a malicious program can as well, no?

A malicious flatpak or malicious program installed via e.g. dnf? If you mean a malicious program on your system which runs unsandboxed, this is nothing you need to worry about.

org.freedesktop.portal.FileChooser=none

org.freedesktop.portal.FileChooser is an interface and not an bus name.

Is there any other, however hackish way to disallow the use of the filechooser?

Maybe FLATPAK_DBUSPROXY=<wrapper script> flatpak run …?

[eike-fokken]

If you mean a malicious program on your system which runs unsandboxed, this is nothing you need to worry about.

What I really meant is this: Which pieces of software do I have to trust to be sure that I really need user intervention for the filechooser to grant permission to a file.

org.freedesktop.portal.FileChooser is an interface and not an bus name.

I simply copied from @Arxcis s answer above. Unfortunately I don't know much about the settings of flatpak up to now. I always used Flatseal for setting permissions.

Maybe FLATPAK_DBUSPROXY= flatpak run …?

Could you elaborate on that? Apparently that environment variable is used in the tests but other than that I can't find much on it.

[smcv]

If I, the user, can grant the read permission in the filechooser portal, probably a malicious program can as well, no?

No, a malicious program inside a Flatpak sandbox cannot use the portal to grant itself read permission on arbitrary files outside the sandbox.

The "Open" or "Save As" dialog is presented by a separate program outside the sandbox (xdg-desktop-portal-gtk, or some other portal backend like the -gnome or -kde implementations). Programs outside the sandbox are not protected by Flatpak, and can read and write all your files already.

After you select a file to open, the xdg-desktop-portal implementation makes that file appear in a FUSE filesystem inside the sandbox (with read or read/write permissions, depending which file-chooser you were interacting with), so that the less-trusted program can access that file (but not others).

Making this happen transparently, without having to use something like Flatseal, is the entire point of the file-chooser portal (which is responsible for the "Open" or "Save As" dialog), and the documents portal (which is responsible for the FUSE filesystem).

Which pieces of software do I have to trust to be sure that I really need user intervention for the filechooser to grant permission to a file

You need to trust anything that runs outside the Flatpak sandbox, in particular:

• Flatpak itself
• xdg-desktop-portal
• Whatever xdg-desktop-portal backend you are using, for example xdg-desktop-portal-gtk
• the Linux kernel

For completeness: if you have a Flatpak app installed that has been given permissions that would allow it to execute arbitrary code outside its sandbox, then you also need to trust that app. These permissions are the ones you manage with tools like Flatseal and flatpak override. Typically, IDEs like GNOME Builder have these elevated permissions, because they would not be useful otherwise. Ordinary apps like GNOME Web (Epiphany) do not.

[smcv]

should the lines

[Session Bus Policy]
org.freedesktop.portal.FileChooser=none 

have the effect of disallowing the filechooser dialogue?

No, for two reasons:

1. D-Bus permissions like talk only act on bus names, not interface names. Bus names are "larger" than interface names. org.freedesktop.portal.FileChooser is one of several interfaces implemented by xdg-desktop-portal. Its bus name is org.freedesktop.portal.Desktop.
2. There is a special-case for access to bus names matching org.freedesktop.portal.*, which are always allowed. Most non-portal bus names like com.example.One or org.freedesktop.Two are only allowed if there is an explicit talk permission. However, the portal names are always allowed, because the purpose of a portal is that it takes responsibility for doing appropriate permissions handling (either from configuration, or by prompting the user interactively, or whatever) before taking privileged actions outside the sandbox on a sandboxed app's behalf.

(For completeness: there is also special handling for org.freedesktop.DBus, which needs to be partially allowed by default, otherwise D-Bus communication would not work at all.)

[eike-fokken]

Ok, sounds reasonable. Although if I understand correctly, more security could be gained if I could choose to not use a portal and instead make the file dialog of an app also honor the permissions set in the flatpak config file. In that case I would only need to trust flatpak and its sandbox implementation and of course the kernel.

I must say, this is not paranoid enough for my taste, but I also understand that flatpak chooses different trade-offs.

[thomasdevriese]

Hi, I'm running Chromium inside Flatpak, and one of the requirements is to prevent the user from downloading and uploading files (just seeing the file structure of the host system is also strictly prohibited). My idea was to disable the filechooser portal, but if I read this thread correctly, this would not be possible? Does someone know if there are any other ways to achieve this?

I also thought of setting the disable-save-to-disk property to true, but it seems I can't communicate with the org.freedesktop.impl.portal.Lockdown interface as it is not under the org.freedesktop.portal.Desktop bus.

Thanks!

[orowith2os]

@smcv even blocking org.freedesktop.portal.Desktop, org.freedesktop.portal., and org.freedesktop. doesn't work to disable filechooser portal access, it seems.

@TheEvilSkeleton is having issues with disabling it to work around an issue with Krita (https://bugs.kde.org/show_bug.cgi?id=438608). Does Flatpak hard-code the permissions for these interfaces still?

[rusty-snake]

There is a special-case for access to bus names matching org.freedesktop.portal.*, which are always allowed.

[prahal]

flatpak does not really give a way to set file permission per application but per sandbox (even if most flatpak sandboxes are holding only one application).

To me, the wish of the OP is to control file access per application. Neither flaptak nor portal is meant to provide this feature.

The OP asking for flatpak file permission model to control portal too is not required to achieve his goal.
Looks to me this is the job for AppArmor or SELinux, though I don't know if one can add filters for these for flatpak packaged applications.

[Mikenux]

Perhaps it is necessary to determine if Flatpak requires changes so that any tools limiting file access can limit it to Flatpak apps?

Additionally, reading the use case of disallowing downloading and uploading of files (#3977 (comment)). I think it makes sense to disable the display of the file chooser. Indeed (and if this is not already the case), it would make no sense to present users with a file chooser if they are not allowed to access any files.

[ssokolow]

Fundamentally, Flatpak's design philosophy is built around "If a user asks for something and gets told they can't do it, they'll blame Flatpak and seek to replace it with another distribution channel".

Flatpak isn't a MAC system like SELinux. It's about constraining the programs to what the user asks for, not about constraining the user to some kind of system policy.

...so any constraints on what the user can do must very visibly not be tied to the presence or absence of Flatpak. (Which is a good idea anyway, because tying system policy constraints too strongly to Flatpak just gives you a false sense of security in the face of confused deputy exploits.)

I'm reminded of how classic Mac OS made making a bootable backup as simple as clicking and dragging the System folder onto another device. Don't design around your understanding of the technicals... design around a novice's intuition about how things should work, regardless of underlying implementation.