flatpak installation permission requirements different from ubuntu software

[Seth Arnold]

https://lists.ubuntu.com/archives/technical-board/2021-June/002560.html

The flatpak tools in Ubuntu have different rules for installing packages
than we use in our software center or snap tools:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1812456/comments/14

My summary:
- polkit 'admin' users can configure new flatpak remotes, authenticated by
  password
- unix 'wheel' group users can install and remove packages from configured
  flatpak remotes, without password

This is in contrast to our apt and snap configuration, where only updates
can be installed without authentication, but new packages require using
sudo or a polkit 'admin' authentication to ensure a human is in the loop.

Several arguments for leaving it alone:
- the status quo
- existing documentation
- consistency in the flatpak ecosystem regardless of distribution
- maintaining a delta from Debian for this would carry long-term costs

Several arguments for making changes:
- consistency in the Ubuntu experience
- the wheel group has historical usage; growing the privileges available
  to the group in this fashion may not be welcome at all sites
- installing software is often a restricted operation at many sites

Possible changes:
- always require password authentication when installing or removing
  packages
- change the group that has magical unauthenticated powers
- change the ubuntu software center and / or snap to match flatpak
- document the behaviour in hardening guides and sysadmin guides

Of course there may be reasons for, reasons against, or possible changes
that I did not consider.

At least one flavour is intending to include flatpaks via a deb post-inst
script, perhaps in their default install, so the scope is extending a
bit beyond the status quo "people who have chosen to install flatpak":
https://lists.ubuntu.com/archives/ubuntu-release/2021-June/005235.html

[Robie Basak (racb)]

Thank you Seth for raising this.

For clarity on the current status of this, the decision-making part of what is appropriate to do in Ubuntu here has been delegated by the Technical Board to the Ubuntu Security Team: https://irclogs.ubuntu.com/2021/09/14/%23ubuntu-meeting.html#t19:17

[Seth Arnold (seth-arnold)]

This bug is part of the security team's process -- I know I'm in favor of standardizing flatpak's rules to match apt and snap so the experience is consistent across Ubuntu.

Alex? Marc? et al?

Thanks

[Alex Murray (alexmurray)]

Yes the security team favors both consistency and the principle of least surprise for users here - ie. flatpak should follow the same model as apt/snaps on Ubuntu so that no matter what mechanism is used to install a particular application, the user gets the same consistent experience in terms of being prompted for authorisation etc around updates and the like.

As such, installation of new apps via flatpak should use polkit to authorise the transaction - whilst upgrades should not.

[Simon McVittie (smcv)]

I would recommend that Ubuntu either uses the Debian package as-is, or branches from the Debian packaging to apply whatever divergence is desired. I'd be happy to let Ubuntu maintainers of flatpak use the `ubuntu/*` namespace on Salsa for this, similar to how gnome-shell is packaged.

Obviously I'm only a Debian and upstream maintainer of Flatpak, and not an Ubuntu developer; if Ubuntu people want to diverge, that's their choice to make, although I would encourage prospective Ubuntu maintainers to consider the maintenance cost of divergence before diverging.

> - unix 'wheel' group users can install and remove packages from configured
> flatpak remotes, without password

Where are you getting this from? From upstream, or from Ubuntu packaging?

The upstream default is the wheel group, but the Debian packaging configures flatpak `--with-privileged-group=sudo`, which should mean that the privileged (root-equivalent) group is `sudo` rather than `wheel`. I would hope that Ubuntu inherits that configuration change.

> As such, installation of new apps via flatpak should use polkit to authorise the transaction -
> whilst upgrades should not.

Deleting the custom polkit policy (/var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.Flatpak.pkla and/or /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules, depending which polkit version Ubuntu is using) might be enough to get this behaviour. Please see /usr/share/polkit-1/actions/org.freedesktop.Flatpak.policy for details of what will happen if those files are deleted.

Please bear in mind that upgrading an app might require installing a new runtime for it to run on (for example, upgrading org.gnome.Recipes might switch its required runtime from org.gnome.Platform//40 to org.gnome.Platform//41, or upgrading com.valvesoftware.SteamLink might switch its required runtime from org.freedesktop.Platform//20.08 to org.freedesktop.Platform//21.08), so even if org.freedesktop.Flatpak.app-install requires authentication, it might be desirable for org.freedesktop.Flatpak.runtime-install to not require authentication.

[Simon McVittie (smcv)]

With Debian maintainer hat on, I'm willing to have a limited amount of DEB_VENDOR conditionalization in the Debian packaging, like the way we used to compile xdg-desktop-portal with --disable-pipewire before pipewire was available in Ubuntu main.

However, I draw the line at applying Ubuntu-specific patches in Debian; if Ubuntu wants those, then branching the packaging will be necessary.

[Jeff (jeff09)]

Can confirm the principle of least surprise being violated here. It took me getting a permission error trying to replace a file to test a bugfix to realize that:
- Commands without explicit permission elevation do system-wide modifications
- A theoretically user level setup is not fully covered by the backup of user files due to modifications escaping outside of the environment modifiable by the user
- Storage usage sneaked out of the expected scope (home of the user). Not meaning just installed programs, but ".removed" and "repo" added up to double digit GiBs, towering above the "app" and "runtime" sizes the user is shown during installation

The mentioned issues all stem from the problem that elevation is done with no notice and the usual barriers missing like either having to use sudo, or (worse case) being asked for a password instead of just denying the operation without being root.
However, circumventing the password requirement for privilege escalation presents an interesting dilemma:
- Either passwordless sudo is not a security issue as the user is expected to keep his account secure, and the additional obstacle of entering the password doesn't provide (much) security
- Or the extra step of requiring a password can be relied on as a security feature, therefore a combo of app-uninstall + modify-repo + app-install with a malicious repository could be used for interactive privilege escalation in some cases

Not completely on-topic, but as there's a divergence in privilege elevation here, I'll add an extra concern and question:
As hardware security key support is starting to look good, how will it be possible to use one universally for privilege elevation? As I understand, PolKit is mostly independent from PAM, so merely requiring pam_u2f.so for sudo as a second factor might not provide any extra security if PolKit would be still okay with just the password.
Can't say I'm a huge fan of PAM, but the centralized configuration surely seems to have an advantage, especially in such cases like this where a project is allowed to "slip" in rules lowering the security requirements for system modification.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.