When Ubuntu asks for an admin user's password, how does it decide which administrative user to ask for?

Solution 1:

First of all let to point out that privileged actions are allowed for a non-root user through two different mechanisms.

1. sudo

2. PolicyKit

The first one is used when you explicitly run a command with sudo or a menu item whose command is wrapped with gksu (like Synaptic Package Manager).
In this case the password required is that of the invoking user, usually the user logged in.

The second one is used when a PolicyKit-aware application try to perform a privileged action. In such a case the application asks the PolicyKit Local Authority (through D-Bus) if the action can be executed. The Local Authority then, through an Authentication Agent, asks the active user to prove its identity. The dialog windows is like the following (unfortunately with text in italian :)

You can identify PolicyKit from the little black triangle and the label Details. As you can see, if more that one user is in the admin group, you can choose from the list which user to use for authentication.

Given all this, both sudo and PolicyKit are much more complicated, with respect to the configurations that can be achieved: you can configure action that can be executed without password, executed only by a particular user or group, etc.

Coming to your question, when the mechanism used by the application is PolicyKit, independently from the current logged in user, the password required would be that of Bob or Alice (the only two admin user, if I understand correctly), and you can change from the list which user you want to use for authentication.

When the mechanism used by the application is sudo (for admin tasks performed through GUI this is becoming less frequent), you have no immediate and simple mean to choose the user for authentication.

Solution 2:

Clearly, sudo would be the first choice for me in such a case. The major point appears to be that most (actual) admins don't actually use /etc/sudoers to its fullest possible extent (User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

Most admins end up using only some of the existing rules and adding users, or worse, simply adding users to the sudo group for which a rule usually exists on Ubuntu setups (%sudo ...). This, of course, gives the respective users free reign and the full power of the superuser account.

Given your comment:

so I added them to /etc/sudoers

I reckon you also don't use it to the extent possible.

In a scenario such as yours I would literally script the few actions to which Bob is to be limited. In fact this is what I did on a server that I maintain, to allow two particular users to reboot a particular KVM guest on a host. The scripts would contain a hashbang with absolute path to the interpreter (e.g. #!/bin/dash instead of #!/usr/bin/env bash) and probably run with a shell that is used elsewhere for privileged tasks (/bin/dash or /bin/sh). Those are just precautions. Other than that, I would make sure to hardcode all the absolute paths to binaries and use as few of them as possible. E.g. when using bash/dash I would prefer builtins over commands (see man bash). You can make this maintainable by assigning a variable the absolute path and referring to the program based on that variable ($VIRSH instead of /usr/bin/virsh). If you can, vet the code of any external scripts before calling them. Especially if you need to call them in a privileged context. In my case I also confine the users to a particular root directory and a particular SSH subsystem as they only connect to the machine via sshd and public key authentication. Obviously you don't need that.

Make sure to chown root: <the-script>; chmod u=rw,a=,a+rx <the-script> to prevent anyone but root proper from tinkering with it. Also be careful with setuid and setgid bits enabled on target binaries (find can be used to spot them). Let's assume for the moment that your script resides in /usr/sbin/priv-action.

Now edit your /etc/sudoers. noexec can be used to prevent other binaries than those explicitly allowed as well. There are actually plenty of additional settings, not just those I am describing here. So make sure to consult man sudoers.

Now I prefer to name the users (User_Alias) in my sudoers file, but you could just as well use a Group_Alias (man sudoers) or an actual system group (e.g. %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

and then add a command alias to allow executing that particular script:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Last but not least comes the magic line to allow bob (or rather the users listed under LIMITED_ADMINS) to execute the privileged commands via the script:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

Unlike the previous alias definitions that line requires an explanation. So let's first dig into the parts on a "User Specification" line mean. Here man sudoers helps:

The basic structure of a user specification is who where = (as_whom) what.

Example line (found on most Ubuntu setups):

root    ALL=(ALL) ALL

This says that a user named root (use #0 to tie it to the UID 0) may, on all hosts, run under any user context anything but will be asked for his password (assuming default behavior). Adding the NOPASSWD tag before the last ALL would then also allow root to do the same without being asked for a password (like so: root ALL=(ALL) NOPASSWD:ALL). ALL is an intrinsic wildcard alias for the various alias types.

But back to Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

would allow bob and other listed members of the User_Alias LIMITED_ADMINS to run (on all hosts, that's what the ALL is for) as user root (group implied, but could be given, see man sudoers) the commands given in the Cmnd_Alias PRIV_ACTION. It gets better. Still assuming you write this script, you could allow various parameters, thereby avoiding to write multiple scripts. /etc/sudoers gladly takes shell-like wildcards to limit the possibilities of arguments allowed to be passed.

I have consistently found that admins don't use sudoers the way it should be used, which is why I appreciated the respective "Hack" from the two books "Linux Server Hacks" and "Linux Server Hacks Volume Two", which got me started with a more sophisticated use of this great facility.

You can come up with all kinds of convoluted - which may not exactly help the security aspect - solutions for your particular case, but once you speak the basic vocabulary of /etc/sudoers you can perform quite magic feats :)

NB: keep in mind that you can also create a new file underneath /etc/sudoers.d/ if you feel so inclined. This assumes your /etc/sudoers contains the line:

#includedir /etc/sudoers.d