Group 4-b: polkitd refuses to cooperate
polkitd – an introduction
In order to prevent things from going haywire on a computer, every sensible
operating system enforces a separation of privileges between user and system
processes.
Whereas the former act on behalf of the user who can directly control them, the
latter act on behalf of the operating system and are at most indirectly
affected by a user's actions, but it may happen that an unprivileged process
must communicate with a privileged one.
Dependent on the action to be executed this may be rather harmless, which
justifies granting it, but occasionally it may happen that a critical action is
requested. It is important in this case that this action isn't simply executed
lest every user could, for example, install or uninstall any programs,
possibly with fatal consequences.
Here polkitd intervenes and determines based on a
predefined set of rules what access to grant and what to deny, or when to
request authorization by a third party, respectively. However, sometimes there
are situations in which polkitd kills a request that
normally could have been granted instead.
This makes it necessary to adjust the set of rules.
These rules may be found at two locations:
- /usr/share/polkit-1
- /etc/polkit-1/rules.d
These may come in the form of both scripts to be executed by
polkitd and XML files that tell the daemon the
current set of rules, and depending on the distribution it may be necessary to
access a particular directory to adjust the security settings.
With openSuSE, for example, you are going to succeed in the directory
/etc/polkit-1/rules.d whereas under Debian it is
necessary to modify the XML files in
/usr/share/polkit-1/actions.
The only problem under openSuSE is the fact that the rules seem to be extremely
cryptic, and the ordering of the permissions seems to be counter-intuitive
(the value for the active user comes last in the arrays – the first value sets
the permissions for all other users).
You may define how polkitd is supposed to react for
each of the three categories of users (active, inactive, and any):
Rule | Meaning |
---|---|
no | Deny the action. |
yes | Grant the action. |
auth_self | Request the user password before granting the action. |
auth_self_session | Request the user password before granting the action. Remember the password for the current session. |
auth_self_keep | Request the user password before granting the action. Remember the password across individual sessions. |
auth_admin | Request the superuser password before granting the action. |
auth_admin_session | Request the superuser password before granting the action. Remember the password for the current session. |
auth_admin_keep | Request the superuser password before granting the action. Remember the password across individual sessions. |
So when a process suddenly refuses to comply, you are advised to examine the permissions to find out how things are set and make adjustments where necessary. You merely have to tell polkitd to read the new settings afterwards.
- Open a terminal and log in as root.
- Switch to the directory /etc/polkit-1/rules.d.
- Copy the file 90-default-privs.rules to 10-local.rules.
- Load the file 10-local.rules into your editor.
- Look for any entries that refer to the process going haywire and clear out all other entries if necessary.
- Adjust the rules defined therein to suit your needs.
- Save the file.
In case that you are required to adjust other rules you may simply copy them from the file 90-default-privs.rules to 10-local.rules and adjust them to suit your needs. This retains your rules even when polkitd is updated and the file 90-default-privs.rules is overwritten in this process.
Caution!
Please make up your mind thoroughly on which access permisions you are going to
adjust! Even though there may be multiple entries for the same process, it
won't be constructive to undiscriminatingly adjust everything, because every
entry refers to other permissions granted by the same process!
For example, it doesn't make sense to grant access to the configuration dialog
of a network connection when you merely want to grant a user to bring up or
take down any of the network connections. You are even going to invite a lot of
trouble when you are granting access at the wrong spot, because you enable
every user to mess around with the system!
Here less is more, and in the case of doubt you shouldn't unconditionally grant
access to a particular resource, but link successfully granting it to providing
e. g. the superuser password!
After you are done with any adjustments, simply restart polkitd: systemctl restart polkitd.service
to the topNetworkManager cannot be controlled
When locally logging in to a computer, NetworkManager works as usual: When you want to connect to another network – normally a wireless network – you simply select it, and NetworkManager takes care of the rest.
When you are logging in via XDMCP, things should work exactly the same – or so
one could think.
But far from that! When you attempt to connect to
another network, NetworkManager lapidarily answers the attempt with a message
that the action were not permitted.
Here one could come to think that NetworkManager is misbehaving when attempting
to connect via a network, but that's not the case. In this case the security
settings of polkitd are playing a prank on you, which
constitutes a problem especially when attempting to access a VPN.
Although it is legit to protect cabled connections against accidental
disconnection for the remote box to stay reachable, it also prevents accessing
any VPN, and when the VPN connection isn't supposed to stay open all the time,
launching the respective VPN daemon isn't feasible. It is therefore necessary
to relax the security settings of polkitd in such a
fashion that one cannot accidentally disconnect a network connection, but still
grant access to any VPN as long as the correct password (normally that one
belonging to the system's admin) is provided. This gives you ample warning in
case that you have selected the wrong connection and allows you to simply
cancel the request, and when you have selected the correct connection, you
simply need to provide root's password.
However, here the all-important question is which settings for NetworkManager
need to be adjusted for everything to run smoothly. Here the following command
comes to your aid:
cat /etc/polkit-1/rules.d/90-default-privs.rules | grep
-A 1 NetworkManager.
The command cat lets you display the contents of a
file. Here the file with the default settings is of a particular interest for
us so we are going to have its contents displayed.
Since we don't want to see the entire heap of data we are going to have the
desired entries together with their associated settings. The tool
grep does this for us by evaluating the output from
cat according to a
regular expression and
displaying any matching spots.
Only a single setting marked with the identifier
org.freedesktop.NetworkManager.network-control is of
interest for us. Look for this string and examine the following line. You are
going to find these values: [ 'no', 'no', 'yes' ].
This grants control over any local networks only to local users with an active
session. All other users are denied this privilege.
However, for our purposes this is not acceptable, therefore adjust the settings
like this: [ 'auth_admin', 'auth_admin', 'yes' ].
After restarting polkitd you may use any existing
connections in the future even when you are logged in via XDMCP. In this case
you are asked for the superuser (aka. root) password
to confirm the action. Upon successful confirmation it is granted.
Beware!
Don't disconnect the physical connection under any circumstances when you are logged in from a remote box! You are cutting off your access via the network, and in order to restore the connection, someone is required to log in locally – or failing that the box must be restarted altogether. It is therefore more viable to request providing a password, because that gives you the chance to cancel the process when you discover that you have picked the wrong connection.
PackageKit constantly requests root's password
When you have logged in to your computer you may update your system without
problems, that is, without the package management requesting a password.
As long as you stay logged in locally this is not a problem. However, things
look entirely differently as soon as you log in via network from another box,
for example via XDMCP. In this case PackageKit
obtrusively requests the superuser password from you, be it for updating
outdated packages, be it for simply updating its package list or even when you
need to accept a license agreement. This becomes extremely annoying in the long
run.
In order to mitigate this problem it is necessary to adjust a few rules. The entries with the following identifiers are of particular interest for us:
- org.freedesktop.packagekit.system-update
- org.freedesktop.packagekit.trigger-offline-update
- org.freedesktop.packagekit.system-sources-refresh
- org.freedesktop.packagekit.package-eula-accept
When you have a look at these settings you are going to notice that all of them
are set to
[ 'auth_admin_keep', 'auth_admin_keep', 'yes' ] with
the exception of
org.freedesktop.packagekit.system-sources-refresh
(the latter has been set to
[ 'auth_admin_keep', 'no', 'yes' ] instead).
However, for our purposes this is not acceptable, because you are required to
confirm even the tiniest of actions. The annoyance level of such a proceeding
is completely out of relation to its use – what damage could updating the
system, which is by design supposed to instead eliminate any insecurities in
the system and any programs, possibly do?
In order to do away with the irritating requests for the superuser password
once and for all, you simply have to set all four entries to the following
values: [ 'yes', 'yes', 'yes' ].
After restarting polkitd you aren't going to be asked
for the superuser password any more, but the package management is going to
look for any updates on its own, and once you launch the update, it is going to
happen without further queries. The only thing that may happen is that you need
to accept a license agreement if applicable, but here clicking on “Accept”
suffices to have the package installed. A query for the superuser password thus
isn't applicable here, either.