Restrict some portals to focused applications

[hadess]

Some of the portals, like the ones spawning dialogues, or launching URLs in remote handlers (Web, mail, etc.) should probably not do anything if the requester application is not focused, which would mean that the application programmatically generated this action, rather than the user.

Similarly joysticks, geolocation, are things that you might want to disallow once the application loses focus.

(for geolocation, it's a bit more complicated, some applications should be able to only access geolocation information when focused, for others, all the time, eg. an app to do social media checkins for the former, a navigation application for the latter)

[matthiasclasen]

We discussed this a bit at the flatpak bof - application life-cycle, foreground/background apps, etc.
This needs some careful planning and infrastructure.

[matthiasclasen]

I've asked Jonas to draft a shell api for this.

[jadahl]

I have a gnome-shell branch that adds a D-Bus API that the portal can use to see what application is active. The API can be seen here: https://gitlab.gnome.org/jadahl/gnome-shell/blob/wip/introspect/data/org.gnome.Shell.Introspect.xml .

Some things to note:

• It currently excludes "applications" that don't have toplevel (non-transient) windows, such as xdg-desktop-portal-gtk if it only has transient portals
  • This means xdg-desktop-portal-gtk and the like will be standalone applications if it has standalone (non-transient) dialogs
• It'll take the focused window, go up the transient window tree to the most top level window, and assume the application of that window is the "active"

• This means that if e.g. portals are focused, the "active application" will be the one the portal is transient to

• There is no protection regarding non-sandboxed application lying. E.g. a non-sandboxed application can pretend to be the window of a sandboxed application. Any reason to deal with this?
• I don't expose whether the application is using Wayland or X11, and after some thought, I don't think it should be part of the API, as is already possible to know whether the application has access to X11 or not, and that is more relevant than whether it has open / focused windows using X11.

[matthiasclasen]

looks like a good start. thanks for doing this. So, to recap:

app-id not in the list -> "background" (ie running app without open windows)
app-id in the list, with an "active-on-seats" key -> "foreground" (an app window has focus)

[matthiasclasen]

We have all the infrastructure in place to do this now - we know which applications are in the background, and which is active.

What we need now is a concrete suggestion for a policy to implement

[Firstbober]

Any progress here? Gnome can do it as shown above, and wlroots with wlr-foreign-toplevel-management-unstable protocol also can.

[RokeJulianLockhart]

#42 (comment)

@hadess, please allow the user to disable this restriction as #325 (comment) describes.

[Mikenux]

@RokeJulianLockhart : Could you give the cases and reasons why this should be disableable? It would help to understand the issues it can cause. Thanks!

[RokeJulianLockhart]

#42 (comment)

@Mikenux, I'd like to be able to develop software for myself that doesn't whatsoever need this kind of restriction. I and some others use flatpak as a means of application distribution rather than a sandbox. They're very different purposes.

Ideally, all of these restrictions should be disableable anyway, though, right? Different people need different levels of security, and I can't imagine that disabling this code would be too difficult to implement – just if-elses. Flatseal demonstrates this well.

[Mikenux]

@RokeJulianLockhart:

In my opinion, this restriction should not be able to be disabled, at least for applications using portals "spawning dialogues, or launching URLs in remote handlers". My reasoning for such cases is that if disabling the restriction is possible, any malicious developer can tell their (naive) users to disable this, and thus allow the malicious app of this dev to open many apps (if allowed ) to try to crash the system (for example). This is probably an extreme case, but it is something to avoid. The fact that this restriction cannot be disabled prevents developers from implementing such things when using portals.

Also, keep in mind that this will be limited to portals. So if you don't use the sandbox part, so not the portals, that won't be a problem. If you use portals, then you must respect the restrictions imposed by them. If a portal is disabled, focus restriction will be disabled for that portal. However, if you want to use the portals while disabling this restriction for them, I think it is better to know for what precise uses you want to disable it.

[RokeJulianLockhart]

#42 (comment)

@Mikenux, aren't portals also used for cross-DE native functions instead of programming each DE-specific function in? Firefox uses the XDG-FILE-PICKER portal even when it's not installed with flatpak, according to about:config.

Additionally, the argument that a malicious actor could ask a user to disable a security feature applies to literally everything. I've had people mention that they were asked to disable secure boot by a virus (which actually stopped the virus actually installing, since it broke the boot process, but it counts) and all manner of other weird things. We can't fix incompetence, especially not to the detriment of developers.

I'm no brilliant software developer, and mandatory security features like these will prevent me using flatpak and its portal functionality because I don't want any restrictions on the software I make for myself.

[Mikenux]

@RokeJulianLockhart

aren't portals also used for cross-DE native functions instead of programming each DE-specific function in?

If something is developed, it's better if the different DEs follow... I can't tell you more. A flatpak developer will best answer this question.

Firefox uses the XDG-FILE-PICKER portal even when it's not installed with flatpak, according to about:config.

I read that portals can be used by unsandboxed applications. But, again, a flatpak developer will best answer this.

the argument that a malicious actor could ask a user to disable a security feature applies to literally everything.

Indeed. It's something to think about. However, keep in mind that this restriction must be thought out for each portal. As said in the first post, this is difficult for apps that need to use geolocation, so maybe it won't even apply to that. That's why it's best to say now for which specific use cases you don't want a permission "removed" when an app loses focus (and regains it when refocused).

[RokeJulianLockhart]

#42 (comment)

@Mikenux, I staunchly believe that the best solution to this issue is the implementation of a global/system-wide permissions override system for portals which would allow the portals to be by default configured by flatpak to be restricted to focussed apps whilst allowing a tech-savvy (anyone who dares to use a CLI is enough in that ballpark) to disable this protection.

The best security solution is a great default to an ultimately configurable preference. Anything more restrictive prevents developers and users using the software, and anything less makes the feature redundant outside a corporate/managed setting.

We can't stop someone like the developer of Flatseal providing a nice GUI to it, but anyone who downloads Flatseal is also adequately competent.

[Mikenux]

As said before, I personally don't see any problem with having something that makes it easier to manage permissions and other features, if the user is properly informed (e.g. having a confirmation UI on disabling a permission/important feature).

However, it is preferable that users or administrators do not have to disable any. So please give your use case, so anyone here can see if any restrictions need to be applied to it when not focused. If restrictions need to be applied, then anyone can think of how to include the exception in an informative user interface for the user. That would help greatly, thanks!

[bbb651]

This can also work the other way around to be more lenient based on other heuristics e.g. for a hypothetical clipboard portal (I'm pretty passionate about clipboard security, the current situation where every app can steal everything from your clipboard silently is really bad, at least it requires focus iirc) pasting could be allowed without a prompt only if ctrl + v is held down (and maybe a notification as well).

@RokeJulianLockhart I think you're hang up on the word "restriction", restriction isn't inherently bad and against user choice. In fact the opposite is true - in the case of portals restriction creates user choice, by restricting applications to a small-as-possible permission-aware interface, it gives user choice to deny access to system peripheral/data and modularizes desktop components - portals are all about restriction. Applications without focus opening permission dialogs is especially bad as currently backends don't do a very good job of identifying the requesting application and a window identifier is optional meaning it's easy to assume a malicious background application's permission dialogue is the focused application's one. If you have a legitimate use case or concern that is productive, please do share it.

[RokeJulianLockhart]

#42 (comment)

@bbb651, my use case is clipboard retention and synchronisation tools. An example is https://github.com/KaustubhPatange/XClipper/releases/download/v0.15.8/XClipper-Portable-x64.tar.gz, as https://github.com/KaustubhPatange/XClipper/wiki/Data-Synchronization/6f7babe866d8ce8ee7b02180cc5d94e0751d0c6f#sharing-data-with-another-pc describes. If this portal restriction were implemented in a manner which isn't possible to override system-wide, user-wide, or at least application-wide, this type of application would be rendered impossible for a standard user to utilize without bypassing the portals and package sandbox.

Generally, we should design restrictions in a manner which evidently caters for use cases which we have not considered, lest we create an API platform like AOSP, i(Pad)OS, or UWP's.

[Mikenux]

@RokeJulianLockhart:

That's the kind of use case I requested.

For clipboard retention, that's about allowing apps from which content is copied to copy their content when they have the focus, and for the clipboard app to paste content only when a target app is focused (so doing what @bbb651 suggested but also knowing what do to when Ctrl+V is not used).

For sync tools, that's allowing to sync at specific times (e.g. app can sync each hour) or always perhaps depending on hints.

Finally, for this issue in general, I think it is something to use on a per-portal basis: up to persons proposing a portal (or changes to an existing portal) to tell if they want to use that for something. They open a discussion, tell if they use app focus and how, and people seeing the proposal can object by saying their use case.

[RokeJulianLockhart]

#42 (comment)

@Mikenux, I would want the synchronisation to be immediate, always. This means that the clipboard manager needs to retain its own initially duplicate (and functionally immutable) copy of the clipboard locally, in order to synchronise it when there is an InterNet connection later. It requires constant and immediate access to the clipboard to facilitate this.

The systems that I'm using could go down at any time (I sometimes have to use them in a military context) so I need to be confident that nothing shall prevent this access arbitrarily in a manner which I cannot foreseeably disable. If XClipper can do that on AOSP of all platforms (and, of course, Windows) it should be able to on Linux DEs.

I want to specify that I do fundamentally support this endeavour to allow the user to restrict access to focussed applications. However, without a way to disable it for each, any, and all scopes, it's not fit for purpose.

[Mikenux]

@bbb651: I have in my notes a clipboard portal that already includes management with app focus and I added your idea of ​​Ctrl+V.

@RokeJulianLockhart: I have included your case in my personal notes.

However, don't expect anything anytime soon as there are other things to consider, especially in the case of synchronization. Just check the Discussions from time to time to see if anyone has posted anything related to your cases.

Now, I don't think it is useful to discuss further on this issue because it is ultimately only a protection mechanism to be used or not in the proposals (this avoids having to overload this issue with comments which ultimately are case by case). Thank you for understanding.