The rationale behind allowing `sudo -u root` but disallowing `sudo -u <any other user>`

Question

I'm working with a customer where I use a functional user ID, created specifically for the purpose, to install and configure some software on multiple servers. The customer's security policies, explained to me verbally, allow them to give to the function ID permissions to use sudo to impersonate the root user, but not any other user. The person I work with cannot explain why this restriction exists.

Can anyone explain what might be the reasons for such a policy?

Answer 1

My guess would be the depth of a corporate policy jungle surrounding non-repudiation in combination with a lack in the communication of technical details.

As example:

• If there is a rule that any action must be traceable to the unique user it might result in a rule "no sudo to another user".
• Then there is likely a rule that forbids logins of root, so "sudo -u root" must be allowed as an exception to that first rule.

Of course, if I sudo to root then I am able to impersonate any other user. This is where the 'lack of communication' comes into play.

In general, the people that actually establish a policy do not possess the technical knowledge required to understand it so they rely on technical people. If these are not able to raise their concerns in a way the managerial folks understand we have a set of rules that sound good for the general public but are less than understandable if you are into the technical details (after all, sudo -u user leaves log entries while with sudo -u root these can be tampered with).

But here we are, reading corporate policies, scratching our heads and thinking "why would anyone consider THIS a good idea?".

Answer 2

My sudo policy let (power: staff) users do some system tasks like

apt install software from known repositories, dynamically mount shared volumes (with hidden root-only credentials) or control system processes and logs

in /etc/sudoers.d, a local policy file could be:

%wheel ALL = (ALL)  NOPASSWD: ALL

%staff ALL = (root) NOPASSWD: /usr/bin/apt

%users ALL = (root) NOPASSWD: /bin/mount
%users ALL = (root) NOPASSWD: /bin/umount
%users ALL = (root) NOPASSWD: /bin/systemctl
%users ALL = (root) NOPASSWD: /bin/journalctl

# %users ALL = (root) NOPASSWD: /sbin/shutdown

while is denied to assume other identities or add unknown PPA repos (apt-add-*), unless (admin) user member of the wheel group.

---

You could "fine" tune privileged access via a custom command interface provided by a sudo-enabled script.

Internally the script can escalate permission, by self invoking via sudo:

#!/bin/sh

if [ ! "$1" = '--sudo' ]; then
   exec sudo $0 --sudo $@
fi

##
# privileded part
#
...

---

UBUNTU user note

everything is useless, unless you change default permission on home directories (cfr. RHEL/Fedora)

chmod 750 $HOME