Allow unprivileged users to update system, require password to change system for everyone
- Initial Change proposal: https://fedoraproject.org/wiki/Changes/better-rpm-ostree-permissions
- Updated Change proposal: https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops
The current polkit rule looks like this:
$ cat /usr/share/polkit-1/rules.d/org.projectatomic.rpmostree1.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.projectatomic.rpmostree1.repo-refresh" &&
subject.active == true && subject.local == true) {
return polkit.Result.YES;
}
if ((action.id == "org.projectatomic.rpmostree1.install-uninstall-packages" ||
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.upgrade" ||
action.id == "org.projectatomic.rpmostree1.rebase" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ||
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;
}
});
To fix 2 issues, I propose this rule instead:
- allow upgrades for nonwheel users (the OS is trusted, the upgrades are very stable, this should not be an issue)
- do not allow any system modifications without a password prompt, for anyone
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;
}
});
Explanation: I rearranged some permissions, allowing all local
and active
users to repo-refresh
, and upgrade
which is necessary for the automatic-update service to work.
Meanwhile, I removed many actions as these can harm a system, install or remove un-/wanted software, change the OS remote to something hostile etc.
These are nontrivial commands wheel users don't need to execute lots of times, so it should be no problem for UX.
The new role will prevent many security problems, like:
- rebase to a previous system with a security vulnerability
- uninstalling an overlaid package that allows the user to hide their IP
- installing a malicious RPM
So this fixes to issues:
- rpm-ostree is now practical for "install and forget" deployments, with automatic version upgrades and zero maintenance. Automatic updates will no longer spit out permission errors but actually work.
- rpm-ostree will require a password for system modifications, placing at least the standard barrier in the way of malicious modifications
Testing
- tested with vanilla Kinoite 40 (KDE) and Silverblue 40 (GNOME) images and their
plasma-discover-rpm-ostree
andgnome-software-rpm-ostree
integrations - tested on both with rpm-ostree in the CLI
possible issues
- anything involving package layering during the install process
- this should open a polkit password prompt, launch the commands with
pkexec
Scope
These do not solve issues with ~/.bashrc
, user $PATH
, ~/.local/share/applications/
and more being writable even by many flatpaks. This means many programs can alias the sudo
or pkexec
command, pipe the password into a random file and forward it to the desired action, making catching the password trivial.
So this does not fix the issue of trust in unprotected executable paths and files. But it is a minimum step.
There may also still be the possibility for "update blocking DDOS" by spamming rpm-ostree repo-refresh
. This should be considered when removing the dependency on local and active users is in question.
Security issues that are fixed
-
install
: install malicious code packaged as RPM -
override
: remove security mechanisms from the base OS -
deploy
: set a random image as boot target -
rebase
: switch the OS origin to a hostile one -
rollback
: revert security patches -
bootconfig
: change boot parameters (?) -
reload-daemon
: possible DDOS attack, blocking updates by permanently reloading -
cancel
: prevent security patches -
cleanup
:cleanup --pending
can block security patches
Question: where is rpm-ostree kargs
located? This still works without a password prompt!
Edit
Update it to the current version.