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

Project Discussion Change Proposals
,
1

Unprivileged updates for Fedora Atomic Desktops

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.

Wiki
Announced

:link: 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.

:link: Owner

:link: 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: Changes/KDEKinoiteAutoUpdateByDefault - Fedora Project Wiki
    • 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:

Initial work in:

:link: Feedback

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

:link: 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 Confined Users Special Interest Group (SIG).

:link: 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

:link: 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.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? No

:link: How To Test

  • Write the following file:

/etc/polkit-1/rules.d/org.projectatomic.rpmostree1.rules

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.bootconfig" ) &&
        subject.active == true &&
        subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.AUTH_ADMIN;
    }
});
  • 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

:link: 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.

:link: Dependencies

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

:link: 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

:link: Documentation

No additional documentation.

:link: Release Notes

To be written once the change is accepted.

Last edited by @boredsquirrel 2024-06-06T20:30:06Z

6 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

The formatting of the new rule is still messed up, will fix it on time

4

To the person that is opposed, please comment the criticism so it can be discussed :slight_smile:

1 Like
5

Your considerations might be from the point of view of an individual who owns the computer and pays for maintaining it.

In this case, to get a more liberate settings for updates would be, to make changes in the /etc/sudoers.d directory with a simple rule. Release the password necessity for the main user who installs the device. Of course other users can be added any time, but this should not happen by default.

Seeing it from an Supporter of a cooperate network and or a Manager whose responsibility is to maintain a secure and a low-cost environment , I would clearly being against such a change by default.
Because in such an environment updates are made automatically and should not influence the employees workflow.

We also already had a discussion about the Update message, not displayed in the Power-save mode. Why would I bother my employees with a update message if I carry costs, time and do the work automatically ? What I would do in such a case is, to inform the employee letting the device on after logout, for maintenance tasks.

2 Likes
6

This is about a polkit rule and not about the sudoers file.

The logic is that a sysadmin would configure automatic updates, and the unprivileged user “runs” them. Actually the system runs them but I guess this is how Linux works.

Currently, the automatic updates service gives an error message on nonwheel users, thats it.

Updates are supposed to be trusted so there is nothing privileged about applying them.

Quite the other way around, the upstream is trusted, updates are atomic and thus failsafe and running them is crucial for getting all security patches.

If you can suggest a way how updates could initiated on a schedule, while restricting users from doing them manually, that could for sure be helpful to document. A system systemd service?

I dont see how this change would worsen the current state though.

Also, in a company I would have my own image server, doing needed modifications and upgrade controls locally, and then distribute through the LAN. (I have not yet experimented with that but especially with OSTree native containers or future bootc containers this should be easy)

I dont get it, what update message? This is not about any GUI integration or discover-notifier, I personally remove the integration entirely as it slows the store down and has no value.

Kinoite and Silverblue update in the background, automatically. There is no message.

There is also no “reboot and update” etc like on traditional Fedora, as the update is done on the live system and staged as next boot target.

This will not change anything about how this works, just enable automatic or manual updates to not error out when the user is not in wheel. Thus, simply making restricted user systems possible.

Fedora Atomic should need a lot less maintenance ;D

uBlue (using OCI OSTree native container images) and possibly bootc images in the future too, even allow automatic version upgrades, when upstream changes the version.

I am on ublue-os/kinoite-main:latest and uBlue decides centrally what branch this represents.

This was pretty off topic but hopefully could clear up some things.

edit: removed incorrect information about other polkit privileges

1 Like
7

We explicitly do not go that route to not depend on sudo and SetUID binaries. rpm-ostree also already uses polkit rules for access control and this change is about changing those. Adding sudo rules would be a new access control mechanism.

Allowing unprivileged users to start updates does not interfere with administrators doing updates. If administrators want to disable this new rule, they can override it the similar way that we suggest testing this change.

This change is not about the user interface nor when the updates are applied. This is the responsibility of GNOME Software or Plasma Discover. This change does not change how updates are presented to users.

2 Likes
8

Those are not newly added privileges. This is how the rules are currently set for Atomic Desktops: Tree - rpms/fedora-release - src.fedoraproject.org

This is also the default for Package Mode Fedora with PackageKit:

Changing this is out of scope for this change.

3 Likes
9

Overlooked that this is only for wheel users.

I would still say, as this change also removes the ability to install random local RPMs, and thus is about more than just unprivileged updates, I would remove it.

But if I understand you correctly, this would require a systemwide Change proposal to require a password for installing packages, always, for all users.

1 Like
10

Yes, this has implications that reach beyond the Atomic Desktops and would be a more general change thus why I kept it out of this change request.

3 Likes
11

Thanks a lot both of you for the clarifications.

What catches my attention on this topic is the title.
You might consider to edit it to something like:

Polkit rule change for unprivileged updates on the Fedora Atomic Desktop Editions/Spins.

I hope that I gotit right now :blush:

12

Polkit runs in the background and the implementation is not important for the desired effect. The title would be too long and a bit technical. The proposal keeps the PRs and more links where the exact implementation can be understood

I/we also plan to document the polkit rule in the Atomic Desktops Doc Chapter, showing how they can be modified for common scenarios.

1 Like
13

I voted I am Strongly opposed. I think a Linux distro should have an administrator who deals with installs and updates. That’s what I have used in the past 16 years and that’s what I want to keep using. This differs a Linux distro from Windows where everyone can install updates. Bad choice.

But why the talk about introducing this in Fedora 41? I use Kinoite 40 and here I also update without a password. It feels not good. I can’t get used to it because I don’t want to get used to it. Linux should have a password for writing on system disks, for installing, for updates, in fact for everything which does not mean writing in your own home folder.

People, don’t get lazy, don’t revert to the time you used Windows. There is a reason why you left that system, think about that.

14

Please read what they said to me 
 it is not about the user and the desktop environment 
 it is to change the rule how the :

It is about controlling the daemon not the user who has to put a password. Check also the second point mentioned above. Control the whole process better. And as I do understand it is about the imutable os part and not the layered software etc.

1 Like
15

I edited the polkit rule formatting, to be better readable, it really was not before.

To explain in detail what this now means:

  • all users can check for updates and update (first block).
  • all admin users (in the wheel group) can do the things in the second block, these are system modifications
  • if a user is an admin, they still need to enter a password when doing the things listed in the 3rd block

2 and 3 are system modifications, only admins can do them.

I think we a agree on the same points:

  1. Non-admins need to be able to use the system
  2. Changing the base system needs to be a privileged action
  3. Some things should require a password (what exactly is a Fedora convention and not in scope of this proposal)

To 1.: Try using Fedora Atomic without being in the wheel group. Automatic updates are now enabled, but as they run form the active user, you will get an error because you dont have the permission to do them.

Updating the system is not privileged in any way. Fedora is not a stable distro, there is no difference between “feature updates” and “security updates”. So updates are security updates and need to be applied as quickly as required.

To 2.: See how nonadmins cannot change anything. Using rpm-ostree, you can “configure” your system by layering or removing packages. Or you leave it as is. Once configured, every update will keep this configuration, the updates will be pulled down, your changes will be applied, and the image is built.

There is no way the user could break something here, or inject malicious things.

Also note: on immutable distros, upstream is the “admin”. They package the system and it is meant to be ran unmodified. Users in the wheel group can still modify it, but after that there is no admin needed. Things go automatically.

And to the 3. with this change we would make the rules more secure by requiring a password for certain actions.

1 Like
16
17

To complete the unprivileged user story, we will likely have to include another rule for system Flatpak updates: Allow Flatpak metadata-refresh without password for non-admins?

This should likely be a distinct Change Request.

3 Likes
18

Could this topic also have something to do with to strong polkit rules?

Might be not 


19

Edit: maybe but not relevant in this thread

So there are 4 people that are opposed to this, please comment here to have concerns addressed.

20

This change proposal has now been submitted to FESCo with ticket #3223 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like