|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| = Better rpm-ostree Permissions =
| | moved to [https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops UnprivilegedUpdatesAtomicDesktops] |
| | |
| {{Change_Proposal_Banner}}
| |
| | |
| == Summary ==
| |
| rpm-ostree currently
| |
| * allows all wheel users to do arbitrary changes to the system without a password prompt. This leads to scenarios like [https://github.com/rohanssrao/silverblue-privesc silverblue privilege escalation] (by default users are in the wheel group)
| |
| * prevents nonwheel users from updating their systems, making many deployments impossible.
| |
| | |
| * Bug: [https://gitlab.com/fedora/ostree/sig/-/issues/7 #7]
| |
| | |
| === Upgrades ===
| |
| On the atomic variants, upgrading the system is not a privileged Action. It can and will be automated and run in the background.
| |
| | |
| The source where the updates come from is trusted.
| |
| | |
| Updating the system atomically is rock solid and does not involve much risk. Instead if includes important security patches, so getting quick updates is a big priority.
| |
| | |
| === System modifications ===
| |
| Meanwhile, modifying the base, changing to another ostree remote, layering, unlayering or removing packages from the base image, are all privileged actions.
| |
| | |
| Layering packages allows to install any RPM to the system base, which can include arbitrary executable code. Installing external RPMs is possible, which means there is no monitoring of their contents.
| |
| | |
| rpm-ostree can use external repositories including COPR, by placing them in `/etc/yum.repos.d/`.
| |
| | |
| rpm-ostree allows many more modifications of the core system like adding or removing kargs.
| |
| | |
| Editing the source of updates (rebasing) is a privileged system modification and can make formerly trusted updates malicious.
| |
| | |
| All these can infect a system with malware or render it unusable, thus these actions are privileged and require guarded privilege escalation.
| |
| | |
| == Owner ==
| |
| | |
| * Name: [[User:boredsquirrel| Henning]]
| |
| * Email: boredsquirrel@secure.mailbox.org
| |
| | |
| I am happy for additional owners :D
| |
| | |
| == Current status ==
| |
| [[Category:InProgress]]
| |
| | |
| <!-- Select proper category, default is Self Contained Change -->
| |
| [[Category:SystemWideChange]]
| |
| | |
| <!-- [[Category:SystemWideChange]] -->
| |
| | |
| * Targeted release: [[Releases/41 | Fedora 41 ]] (Backport to 40 highly advised)
| |
| | |
| * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
| |
| <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
| |
| Bugzilla state meanings:
| |
| ASSIGNED -> accepted by FESCo with ongoing development
| |
| MODIFIED -> change is substantially done and testable
| |
| ON_QA -> change is fully code complete
| |
| -->
| |
| * [<will be assigned by the Wrangler> devel thread]
| |
| * FESCo issue: <will be assigned by the Wrangler>
| |
| * Tracker bug: <will be assigned by the Wrangler>
| |
| * Release notes tracker: <will be assigned by the Wrangler>
| |
| | |
| == Detailed Description ==
| |
| Change the default rpm-ostree polkit rules to
| |
| * allow refresh and update to all local&active users
| |
| * do not allow other actions without a password prompt
| |
| | |
| This fixes the mentioned privilege escalation vector and helps to work towards a system that is possible to use without wheel privileges.
| |
| | |
| Please discuss if local&active needs to be a requirement, or if it may block remote users. Keywords VNC, RDP, Gnome remote login, ssh.
| |
| | |
| See these PRs:
| |
| * [https://src.fedoraproject.org/rpms/fedora-release/pull-request/324 remove arbitrary passwordless permissions]
| |
| * [https://src.fedoraproject.org/rpms/fedora-release/pull-request/325 allow nonwheel users to upgrade]
| |
| | |
| == Feedback ==
| |
| @travier : Split the 2 changes into separate PRs
| |
| | |
| @travier : Keep the dependency on local and active users
| |
| | |
| == Benefit to Fedora ==
| |
| It makes the atomic variants secure against privilege escalation through unprivileged processes and users. Currently the atomic variants are extremely insecure, more insecure than any other Fedora variant.
| |
| | |
| It unbreaks automatic updates, which currently spit out constant errors when the user is not in the wheel group.
| |
| | |
| Thus it opens the possibilities for use in schools, for children, or any other area where admins may not be available, and users should not do changes to the system.
| |
| | |
| == Scope ==
| |
| * Proposal owners:
| |
| <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
| |
| | |
| * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
| |
| | |
| * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue.
| |
| The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
| |
| | |
| * Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
| |
| | |
| * Trademark approval: N/A (not needed for this Change)
| |
| <!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
| |
| | |
| * Alignment with Community Initiatives:
| |
| <!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider -->
| |
| | |
| == Upgrade/compatibility impact ==
| |
| There will be no big changes. Privileged actions like rebase, install, cancel, rollback will from now on require a password.
| |
| | |
| If a `wheel` user enables automatic updates, these will also work in the background for nonwheel users.
| |
| | |
| GUI Stores: plasma-discover and gnome-software (with the integrations) were tested: updates work normally, gnome software also prompts for reboot
| |
| | |
| Both stores dont show RPM packages for installation (by default) but both display the repos used for system updates correctly.
| |
| | |
| == How To Test ==
| |
| | |
| Place the file in the override `/etc` directory:
| |
| | |
| | |
| sudo cat > /etc/polkit-1/rules.d/org.projectatomic.rpmostree1.rules <<EOF
| |
| 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;
| |
| }
| |
| EOF
| |
| | |
| | |
| It will also be active if there is an alternative in the `/usr` directory.
| |
| | |
| == User Experience ==
| |
| | |
| Fedora Atomic Desktop users are not meant to modify the core system more than needed. This change will set the correct barrier of requiring a password for system modifications.
| |
| | |
| Nonwheel users will not notice anything, but a system automatically upgraded in the background is possible now.
| |
| | |
| == Dependencies ==
| |
| * `rpm-ostree`
| |
| * `gnome-software-rpm-ostree`
| |
| * `plasma-discover-rpm-ostree`
| |
| | |
| These projects will be affected:
| |
| * Fedora Atomic Desktops (Silverblue, Kinoite, Budgie Atomic, Sway Atomic)
| |
| * Fedora CoreOS
| |
| * Fedora IOT
| |
| | |
| == Contingency Plan ==
| |
| | |
| The solution is simple and just needs to be merged, once it is decided upon and the PR is updated to the latest branch.
| |
| | |
| A backport to Fedora 40 should be done for the sake of security, as the current status is very insecure.
| |
| | |
| == Documentation ==
| |
| | |
| * [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html polkit docs]
| |
| * [https://coreos.github.io/rpm-ostree/ rpm-ostree docs]
| |
| | |
| == Release Notes ==
| |
| Fix rpm-ostree's polkit permissions to allow upgrades for all users, and require a password for any system modifications.
| |
