[SOLVED]gksu aka gksu-polkit vs local sudoers policy

[jtwdyp]

It just came to my attention that gksu-polkit allows NON-root password to access restricted admin tasks in spite of this line in /etc/sudoers:

Code: Select all

Defaults targetpw   # ask for the password of the target user i.e. root


I'm not sure, but I strongly suspect this is a polkit issue, rather than something limited to gksu. Or I'd simply disable gksu and rely on beesu which doesn't do this...

Is there a way to configure ALL polkit processes to require something like what targetpw does for sudoers, for any/all user access to admin related tasks?

It is my firm belief that people, including myself, simply are not careful enough with any password they use for routine tasks. But when a separate password is required for admin tasks, people are more likely to (among other things) check for shoulder surfers before typing the durned thing in.

So because I NEVER wanted ANY process to allow the use of a mundane every day password to authenticate admin tasks. I started setting targetpw in the sudoers a long time ago.

At the time it seemed to work with any installed GUI "SU" tool that didn't automatically want the root password anyway. But that was even before kde4 had me running to other WM/DE environments... So I guess a few things could of changed a bit since then.

[doktor5000]

sudoers or sudo does not have anything to do with sudo graphical replacements like gksu/kdesu.
polkit does not have anything to do with sudoers. sudo is discouraged for graphical tools.

You need to adjust the polkit policy for each tool or adjust the global polkit policy.
See e.g. https://wiki.archlinux.org/index.php/Po ... identities or especially for your case https://wiki.archlinux.org/index.php/Po ... t_password

[jtwdyp]

Thank you for so nicely pointing me at the exact information I was looking for.

But I'm still slightly confused about one point:

polkit does not have anything to do with sudoers. sudo is discouraged for graphical tools.

Yet:

Limitations

Polkit operates on top of the existing permissions systems in Linux – group membership, administrator status – it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect polkit, e.g. the command line. Therefore it's probably better to use polkit to expand access to privileged services for unprivileged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the sudoers file is still the way to go.

Does that mean that if I were to do the work in sudoers to limit the admin privilege of the Wheel (or other defined admin group) by doing something like:

Code: Select all

# %wheel ALL=(ALL) ALL


And then adding lines like these for each admin function I wanted wheel users to be able to perform:

Code: Select all

%wheel ALL=(ALL) NOPASSWD: /sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
%wheel ALL=/usr/bin/halt


in combination with setting the polkit rule of:

Code: Select all

polkit.addAdminRule(function(action, subject) {
    return ["unix-user:root"];
});


Then would polkit respecting tools like gksu only let wheel members who know the root password halt the system, while still allowing wheel members who don't know it, to perform the defined trivial admin tasks, like mounting and unmounting the cdrom as root?
rules???
Or would I have to micromanage all the defined admin tasks in BOTH sudoers AND polkit, in order to actually have "(semi-)privileged users"???

[doktor5000]

Thank you for so nicely pointing me at the exact information I was looking for.

But I'm still slightly confused about one point:

polkit does not have anything to do with sudoers. sudo is discouraged for graphical tools.

[...]

Actually it is pretty simple.
What you define in /etc/sudoers (e.g. for %wheel - rules for members of the wheel group) is only considered when using sudo.

Or would I have to micromanage all the defined admin tasks in BOTH sudoers AND polkit, in order to actually have "(semi-)privileged users"???

Well, sudo is not used by default, so that is your choice if you want to use it. All graphical tools nowadays use polkit authentication, so for a default installation you would only need to adjust the default systemwide polkit policy.
If you choose to add sudo into the mix, you add that additional management effort on top yourself.