F41 Change Proposal: Unprivileged updates for Fedora Atomic Desktops (Self-Contained)

[Aoife Moloney]

Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-unprivileged-u...

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

We want to update the Polkit rule currently controlling access to the
rpm-ostree daemon on Fedora Atomic Desktops to do the following:
* Enable users to update the system without being an administrator or
typing a password.
* Restrict the current rule for administrators to make more operations
explicitly require a password.

== Owner ==

* [[User:boredsquirrel| Henning]], boredsquirrel(a)secure.mailbox.org
* [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org



== Detailed Description ==

This change tries to address two issues:
* Give more users the permission to update their systems as this
should be an entirely safe operation on Fedora Atomic Desktops.
** Silverblue already automatically update the system and Flatpaks by
default and Kinoite is looking at doing it as well:
https://fedoraproject.org/wiki/Changes/KDEKinoiteAutoUpdateByDefault
** We will thus enable all active and interactive users to update the
system without being an administrator or typing a password.
** Note that this is only about system updates (and repo metadata
updates) and no other operations.
* Reduce access to the most privileged operations of rpm-ostree for
administrators to avoid mistakes.
** The current setup is not directly a security issue as it only
allows those operations for users that are part of the wheel group and
thus assumed to be administrators.
** However, some of those operations can be more dangerous than others
so we should ask the administrator to confirm them or let them do it
via `sudo`.
** Operations such as changing kernel arguments, installing a local
package, rebasing to another image, etc. will thus be removed from the
current Polkit rule and will now require the administrator password,
similarly to calling it via `sudo`.
** Only the install/uninstall packages from the repos, upgrade,
rollback, cancel and cleanup operations will remain password-less, to
match the behavior on package mode Fedora with dnf.

See:
* https://gitlab.com/fedora/ostree/sig/-/issues/7
* https://github.com/rohanssrao/silverblue-privesc/issues/4
* https://bugzilla.redhat.com/show_bug.cgi?id=2203555

Initial work in:
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/324
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/325

== Feedback ==

Nothing here so far beyond comments in the PRs, which have mostly been
addressed.

== Benefit to Fedora ==

This change will make it easier to setup a Fedora system with
non-administrator (unprivileged) users that can still update the
system without administrator intervention. Note that major version
upgrades (rebase operation) will still require privileges (or an
administrator password) for now. This is due to a limit of the current
rpm-ostree interface.

This is also a step towards the goals of the
[https://fedoraproject.org/wiki/SIGs/ConfinedUsers Confined Users
Special Interest Group (SIG)].

== Scope ==

* Proposal owners:
** Implement the change in the polkit rules
** Validate that this changes works on all Fedora Atomic Desktops
(notably with GNOME Software and Plasma Discover)
* Other developers:
** Developers depending on the current polkit rules might have to
adapt their software. We don't know of any software impacted right
now.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Not specificaly

== Upgrade/compatibility impact ==

This change does not remove any interface so it should not have any
impact for users on upgrade. If some of the now "password-full"
operations were used previously, they will now ask for a password.

If administrators previously disabled or overwrote the current polkit
rules, then they might have to update their override for the new
behavior.

== Early Testing (Optional) ==

Do you require 'QA Blueprint' support? No

== How To Test ==

* Write the following file:

`/etc/polkit-1/rules.d/org.projectatomic.rpmostree1.rules`
<pre>
polkit.addRule(function(action, subject) {
    if ((action.id == "org.projectatomic.rpmostree1.repo-refresh" ||
         action.id == "org.projectatomic.rpmostree1.upgrade") &&
        subject.active == true &&
        subject.local == true) {
            return polkit.Result.YES;
    }

    if ((action.id ==
"org.projectatomic.rpmostree1.install-uninstall-packages" ||
         action.id == "org.projectatomic.rpmostree1.rollback" ||
         action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
         action.id == "org.projectatomic.rpmostree1.cancel" ||
         action.id == "org.projectatomic.rpmostree1.cleanup" ||
         action.id == "org.projectatomic.rpmostree1.client-management")
&&
        subject.active == true &&
        subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }

    if ((
         action.id == "org.projectatomic.rpmostree1.install-local-packages" ||
         action.id == "org.projectatomic.rpmostree1.override" ||
         action.id == "org.projectatomic.rpmostree1.deploy" ||
         action.id == "org.projectatomic.rpmostree1.rebase" ||
         action.id == "org.projectatomic.rpmostree1.rollback" ||
         action.id == "org.projectatomic.rpmostree1.bootconfig" ) &&
        subject.active == true &&
        subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.AUTH_ADMIN;
    }
});
</pre>

* Test that normal / unprivileged users can '''only do''' the
following operations '''without a password''':
** Update the system: `rpm-ostree update`
** Refresh the metadata: `rpm-ostree refresh-md`
* Test that admin / privileged users can do the following operations
'''without a password''':
** Install a package from the official Fedora repos: `rpm-ostree install strace`
** Cancel an in-progress transaction: `rpm-ostree cancel`
** Rollback to a previous version: `rpm-ostree rollback`
** Reload the daemon: `rpm-ostree reload`
** Cleanup pending or rollback deployments: `rpm-ostree cleanup`
* Test that admin / privileged users are '''asked a password'''
for
the following operations:
** Install a local RPM package: `rpm-ostree install ./foo.rpm`
** Override replace a package: `rpm-ostree override replace vim-x.y.z.rpm`
** Deploy a specific version: `rpm-ostree deploy 40.20240518.1`
** Rebase to any version: `rpm-ostree rebase ...` (try with Kinoite on
Silverblue, etc.)
** Change kernel argments: `rpm-ostree kargs --append=foo=bar`

== User Experience ==

This change should be mostly transparent for users.

If some of the now "password-full" operations were used previously,
they will now ask for a password.

Unprivileged users will be able to update the system.

== Dependencies ==

The rules are shipped as part of the `fedora-release` RPM. There are
no other dependencies.

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?)
** We can revert the change to the `fedora-release` package at any time.
** Will be done by the change owners.
* Contingency deadline: Beta freeze or final freeze
* Blocks release? No

== Documentation ==

No additional documentation.

== Release Notes ==

To be written once the change is accepted.

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney