[Feature request]: Entitlements, like on the proprietary systems

[AdrianVovk]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

Background: this came up as part of my planning for Secure-locking via homed, as part of my work on integrating systemd-homed w/ GNOME

The proprietary OSs have the ability for the app store vendor (Google, Apple) to grant the app special "entitlements" that permit it to talk to specially privileged APIs after a manual review process. The vendors can also revoke these entitlements from apps that misuse the extra privileges they've been given. These "entitlements' sound a lot like Flatpak static permissions, however I feel that we're missing a couple things that would make static permissions as flexible as entitlements on the proprietary OSs (actually more so, since unlike the proprietary OS the user is ultimately in control w/ Flatpak 😄)

Before I go into the missing features, I want to make clear the philosophy we should be following here: "assume good faith, but be ready for bad actors". Ultimately the "assume good faith" is up to the remote's policy, but I'd expect something like Flathub to behave like they do today: give the apps a review, and if they ask for some entitlement give it to them unless you have good reason not to. The "be ready for bad actors" part requires some technical capability that I don't think we have yet: the remote cannot (and should not be able to, IMO) delete apps that are already installed on a user's system. The remote should, however, be able to mitigate the damage malicious apps are allowed to do

The ability to revoke static permissions from the server-side

Whenever flatpak checks the remote for updates, it should download a server-side static permission revocation list (essentially a Flatpak override file) and apply it. This allows the remote to forcibly disable a static permission for an app that is misusing it without updating the app. This can give the remote some time to investigate exactly what the app is up to, and make a policy decision (unpublish the app, take ownership of the app and replace it with something harmless via an update, etc). Some case-study situations I'm expecting this feature to be useful in:

• An app is published to the app store with innocent intentions so it is published. Then the developer falls victim to a supply-chain attack and releases an update to their app that starts to abuse permissions the app has for malicious purposes. Flathub revokes the app's permissions on the server-side to immediately mitigate the damage, then investigates. The developer discovers the attack, fixes it, updates their security policies, and convinces Flathub that they're now robustly secure again supply-chain attacks like this. Flathub then removes the server-side revocation, so the app can use its permissions again. While the developer was fixing everything, the attacker couldn't abuse the app's existing install-base due to the server-side revocation
• A proprietary app pretends to be innocent to pass review, with innocent reasons to have various static permissions, but then after an update abuses its existing permissions for malicious purposes. Flathub immediately revokes the app's permissions on the server-side, then investigates. It finds that the developers were being outright malicious, so unpublishes the app and bans the developer. The app is marked EOL w/ a message explaining that the developer was being malicious and recommending that the app be uninstalled immediately by the user
• An innocent app is hit by some terrible bug that inadvertently abuses its permissions. Imagine an app that spams notifications because the app's server-side backend is glitching out, or an IDE that gets confused and starts deleting files from ~ on accident, etc. Flathub immediately revokes the app's permissions on the server-side, then investigates. It finds that the app is just buggy. The developers then must collaborate w/ Flathub to fix the bugs, and convince Flathub reviewers that their app won't do this kind of thing again (for the examples above: the app rate-limits the amount of notifications it'll send so that even if the server gets really confused the app won't spam the user; the IDE adds checks to make sure it'll only ever delete files under a certain directory subtree). Then Flathub removes the server-side revocation for the apps.

I'm imagining that such a mechanism should be usable to revoke access to portals too! If we have an app that legitimately has access to the camera portal, but is updated w/ some malware that spies on the user, then Flathub should be able to revoke the app's ability to talk to the camera portal while an investigation is ongoing.

Also, the user should ultimately have permission to ignore the remote's recommendations. The user's Flatpak overrides should take priority over the remote's. So the remote can pass along no-filesystem=home, but the user should be able to override that back to filesystem=home if they really want to.

The ability to protect parts of portal APIs behind arbitrary "entitlements"

The idea here is that portals should be able to gate parts of themselves behind extra scrutiny on the server-side.

To implement this we add a new static permission, "entitlement=...", that takes an arbitrary string in reverse domain name notation. This permission is exposed in the /.flatpak-info file of an app. This will let a portal, or some other safe-to-talk-to API, decide whether or not an app is allowed to do something. Here are some use-cases:

• Notification Portal v2 proposes the ability for apps to claim that a notification it is sending is a severe weather alert, thus letting the app bypass the system's do not disturb settings, mute switch, etc. What we could do is make any app that wishes to send severe weather alert notifications to be finished with --entitlement=org.freedesktop.Portal.Notification.SevereWeather. The notification portal, when receiving a notification from an app that claims to be a severe weather alert will check if the the app's /.flatpak-info file lists org.freedesktop.Portal.Notification.SevereWeather as an allowed entitlement the app has before posting the notification. Flathub, meanwhile, won't publish an app that asks for --entitlement= org.freedesktop.Portal.Notification.SevereWeather but doesn't seem to have any reason to.
• Entitlements can be used to bypass certain permission checks for apps where the whole point is that permission. For example, fancy screenshot apps like Flameshot can have a --entitlement=org.freedesktop.Portal.Screenshot.AllowByDefault finishing arg that tells the screenshot portal to skip asking the user for screenshot permissions and just let the app take screenshots. Flathub reviewers, meanwhile, would put huge amounts of scrutiny on this app when deciding whether or not to publish it
• Entitlements can be used to declare certain content that an app has which the app store may be interested in. For example, if you have an app with ads in it, you may want to add --entitlement=org.flathub.Declare.Ads to declare that your app has ads in it. Flathub reviewers are then notified about this in their dashboards and will review the apps appropriately. Similar declarations that Google Play has: --entitlement=org.flathub.Declare.News (for apps dedicated to serving news), --entitlement=org.flathub.Declare.Financial (for banking/stock/finance apps, so they get reviewed by a legal team), etc. A remote's policies may say that if an app fails to declare content like this it'll get unpublished. I suppose this last use-case can be served by AppStream too, but I suppose there might be some portal somewhere that may want to check what these apps are declaring before letting them do things. For example, the notifications portal may wish to rate-limit notifications for apps that declare org.flathub.Declare.News to prevent spam, or implicitly allow apps that declare org.flathub.Declare.Financial to send higher-priority notifications, or place additional scrutiny/requirements on apps that declare org.flathub.Declare.Ads to disincentivize ads and make tracking more difficult

---

Anyway, feedback is very welcome. I think the ability to revoke static permissions is really important, but having a system to declare arbitrary things the app is entitled to is less important (and probably a bit more contentious...)

[swick]

You're asking for two different things:

1. Portals should make more use of static permissions for certain features
2. Remotes should be able to overwrite static permissions

The first point is just something we have to keep in mind when designing new portals. We also lack a design guideline document so maybe that's something actionable for the first point.

The second point is interesting and I don't see any reason why we shouldn't have a feature like that.

[Mikenux]

For revoking static and portal permissions, why not? What is important here is the implementation on the DE side where we can recommend subscribing to this list and separating it from general updates in case deferred updates are implemented. However, I think you should first see what can be done on the user side. Two ideas:

• Detect "bad" static permissions and help the user manage them (with a GUI) before running the app. Allow launching the app in a restrictive sandbox while informing the user that certain app features might not work. This restrictive mode can ask each time an app is started which file the user wants to open. If the option not to ask every time is present, then handling permission changes is required.
• Although app stores already (logically) inform users of permissions, recommend that they add a mode to disallow or validate the installation of apps with static permissions. This would be an additional protection mechanism in case users don't pay much attention to permissions while browsing and installing apps from app stores.

For portals, also first try to think if anything can be done within the portals themselves. Regarding your examples:

• Notifications. If the user receives an unwanted notification, it may be best to provide them with a quick and easy way to stop receiving notifications from an app and perhaps uninstall it. This can be done for example via a menu on the notifications when they are displayed.
• Bypassing permission check. For this, it’s a clear no because it goes against what portals are for.
• App content. For your examples with notifications, same as above. Additionally, maybe implement some delay between notification presentation on the portal side, taking into account how long they are displayed. In other words, this means presenting a new notification only when another one disappears. This can then give the user time to stop an abusive app by silencing its notifications or even stopping or uninstalling it from a notification if this is implemented. Besides, if it can help remotes, why not, but it may have nothing to do in faltpak though.

[AdrianVovk]

where we can recommend subscribing to this list and separating it from general updates in case deferred updates are implemented

IMO this should happen whenever Flatpak checks for updates and we leave it at that. No need for additional complexity and support in app stores

Maybe we can give the user a config knob to turn it off? But I'm really not a fan of that; not sure why the user would need to opt-out

you should first see what can be done on the user side

IMO if an app is being purposefully abusive or violating the policies of the remote, then the remote should be able to restrict the app without user interaction. Why should the user need to work to keep themselves safe from an app, if we have centralized reviewers @ the remote that allowed the app in the first place and have policies to enforce?

Detect "bad" static permissions

recommend that they add a mode to disallow or validate the installation of apps with static permissions

I think you've missed my point: static permissions aren't bad as a whole, and in many cases they're wanted / necessary.

Telling the user that "hey this app will see your files" does nothing to defend the user from that app becoming malicious after an update (either intentionally, or due to a supply-chain attacK) or from catastrophic bugs that suddenly started happening. Especially if the app legitimately does need access to your home directory.

Plus I don't think we can meaningfully communicate every type of static permission to a user so that they can make an informed choice. We can talk in broad strokes of "safety" (this app is "safe", or "somewhat safe", or "unsafe"), but we really can't get more detailed than that...

If the user receives an unwanted notification, it may be best to provide them with a quick and easy way to stop receiving notifications from an app and perhaps uninstall it

This is a complicated design challenge. Having a big red "uninstall" button on every notification is kinda silly IMO, and if the setting is hidden somewhere (like on Android: press and hold on the notification) many people simply won't find it.

And it's not necessarily about letting a user control the notifications an app sends after the fact. It's about giving remotes more flexibility to enforce policies. With the system I propose, Flathub could meaningfully have a policy saying "your app must not be allowed to send fake weather alerts to bypass do-no-disturb settings" and be able to enforce that policy at review time. Basically it puts up a big red flag for the Flathub reviewers that "this app will try to send weather alerts", and if that doesn't make sense for a given app Flathub reviewers can simply reject the app.

Bypassing permission check. For this, it’s a clear no because it goes against what portals are for

I don't necessarily disagree, but I don't necessarily agree either. Portals are about drawing a reasonable security boundary; loosening restrictions for some classes of apps still makes sense. But I don't really see the problem with making these apps ask for permission on first startup and then behave, especially since they're going to have to write that code anyway (in case the system is configured to ignore these kinds of entitlements)

Additionally, maybe implement some delay between notification presentation on the portal side, taking into account how long they are displayed. In other words, this means presenting a new notification only when another one disappears

Strong NACK. This makes notifications a lot less useful. You can only be notified about one email? On message thread in your IM client?

[Mikenux]

Subscribing to the revocation list is more or less equivalent to what you said:

Also, the user should ultimately have permission to ignore the remote's recommendations.

Either way, you suggested this as a way to have control. The idea of managing "bad" static permissions is also a complementary option. Note that by "bad" static permission I'm talking about bad relative to sandboxing; I'm not saying an app is malicious. For example, ask the user to give the app access only to selected files instead of all files if the app has the static filesystem=home permission. This helps limit the damage in case the app would be malicious. Note that this is not new, there are requests for this and some users/developers use the command line for this.

Regarding deferred updates, if app stores are interested in implementing them, then flatpak will be asked not to check for updates. So there needs to be something for app stores to make an exception to this and check for updating the revocation list, without updating the apps. We may also want to automatically update this list, but update apps manually.

Why should the user need to work to keep themselves safe from an app, if we have centralized reviewers @ the remote that allowed the app in the first place and have policies to enforce?

If you assume that a remote that has reviewers and policies is "secure", yes. However, you can't assume this because users can add any remote and the people managing it can lie about their policies. This also assumes that users have sufficient knowledge to judge this. Users (maybe not developers/all developers), myself included, already trust by default the OS they have installed, which is already not ideal because, unless we are able to review all the code, we are not really able to judge. So, trusting a remote by default because it has reviewers and policies...

This is a complicated design challenge. Having a big red "uninstall" button on every notification is kinda silly IMO, and if the setting is hidden somewhere (like on Android: press and hold on the notification) many people simply won't find it.

I also suggested silencing (disabling) notifications, and talked about a notification menu (obviously triggered via a button). Having the option to uninstall isn't necessarily required (and I know there are already issues adding the option to app icons in the app grid).

And it's not necessarily about letting a user control the notifications an app sends after the fact. It's about giving remotes more flexibility to enforce policies.

User control is one of the key elements of flatpak and portals. Even though we have this revocation list for remotes, maybe the list won't be updated in time in case reviewers notice something problematic after an app has been published and already installed (e.g. an incorrect review, which can happen because humans are humans, sending audio or video data to a server where no one knows what it will do with the data I guess).

Flathub could meaningfully have a policy saying "your app must not be allowed to send fake weather alerts to bypass do-no-disturb settings" and be able to enforce that policy at review time. Basically it puts up a big red flag for the Flathub reviewers that "this app will try to send weather alerts", and if that doesn't make sense for a given app Flathub reviewers can simply reject the app.

This seems more like a thing to be implemented by remotes, and not flatpak itself. That said, it's up to the flatpak developers/maintainers to judge.

Portals are about drawing a reasonable security boundary; loosening restrictions for some classes of apps still makes sense.

Portals are about "drawing a reasonable security boundary" by asking the user for permission. Neither an app nor a remote can decide this because neither of them is considered to be trusted. You can be sure that such a request on xdg-desktop-portal will be rejected in no time, especially since in the case you mention the user is already asked if they agree to allow the app to take screenshots at any time (at least under Wayland).

You can only be notified about one email? On message thread in your IM client?

Poor communication on my part here: I didn't give the idea behind this suggestion. The idea is to ensure that the user can act on a notification to disable notifications from an application in case of unwanted behavior of the application. I tested with notify-send and it already seems to be the case. And, as I said, some things could be implemented on the portal side if we need a common UX for DEs (I don't know if they use the same "notification server" or settings).

[Mikenux]

static permissions aren't bad as a whole, and in many cases they're wanted / necessary.

You need to see if these wanted / necessary static permissions can be converted into dynamic permissions (i.e. portals). Then you can create a portal to grant access to apps to be able to display on the lock screen which depends on apps only using dynamic permissions. Best to open an idea on xdg-desktop-portal (https://github.com/flatpak/xdg-desktop-portal/discussions/new?category=ideas) stating what your goal is, what features you need, and what app behaviors you want to avoid (what is wanted/unwanted). Also check if there are already open issues and discussions about what permissions you need.

[Mikenux]

Any news at least on the permission revocation part? This functionality still remains interesting for what it offers. A simple solution could certainly be found, without getting into user management of this as I suggested as that requires more development (note that I spoke of this user control as being complementary and not as being mandatory).

Could issues be created based on what is ok/not ok?

[Mikenux]

Globally, from my side:

• Permission revocation. OK.
• Entitlement for notifications, with allowing only declared notifications. OK. At least, it seems to be a solution for notifications for which we don't have hints or some conditions. In the absence of knowing how a notification is stylised, this can be used for an UX based on apps to allow to disturb (for any category of notifications). However, I'm waiting for feedback (on the PR) and clear explanations relative to Notification Portal v2.
• Permission bypass. As already said, not ok. Also, the portal you mentioned clearly need to be revised. The only thing to have apps with predefined permissions is for administrators and parents (there are already open issues).
• I need to think more about the entitlements for review purpose and for the example of the News case.

[Mikenux]

• Permission Bypass. Maybe if it is user configurable. This would be an opt-in option of a repository (to be discussed further on what exactly to do).
• Spam prevention for notifications. This is something that needs to be handled by the DE.
• Entitlements for review purposes. This doesn't convince me. Reviewers should pay attention to ads or financial items, regardless of the app. What happens if it is not declared? The app is not reviewed appropriately? If there is something I don't understand about this, please be clearer, especially if you want this to be a general system rather than each repository having its own stuff (because something like that is not really relevant for sandboxing).