11

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?

2 Answers 2

20

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?".

3
  • 1
    sudo -u root /usr/lib/klibc/bin/sh might boggle their minds when it appears in the log when it's clearly executed by an application rather than a user.
    – Joshua
    Feb 2 at 2:40
  • I'd argue I see these kind of rules more when there's a log aggregator server that only a few people have access to. It may be that it aggregates commands per user, making it tough to work out who might be doing a thing if they can hop between users. It may also be a user privacy thing - while I could go look at their home dir as root, it's also then obvious that someone is poking around where they don't have permission to.
    – lupe
    Feb 2 at 17:27
  • 1
    @lupe If I can switch to root I can then switch to any other user, it is just one command more than switching directly to another user. And the privacy thing does not make sense to me. With sudo to user there can be very granular rules which user I'm allowed to impersonate while with sudo root it is a blank 'you may impersonate any user', including the user I want to look at. Even last accessed/modified information, if it exists, will list the target user as the one doing it. It also comes back to log integrity, sudo user is never able to manipulate the logs, while sudo root all bets are off.
    – fleitner
    Feb 2 at 17:50
1

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

4
  • For mount, systemctl and journalctl, ensure that it can not be abused to elevated privileges, see gtfobins.github.io
    – fleitner
    Feb 9 at 13:24
  • 2
    Not just those -- also apt via the same site or that you can install local package files with apt (see superuser.com/a/1244531), and you can easily make your own packages to do whatever you want... It's remarkably easy to accidentally leak root privs via seemingly simple restricted sudo rules! Feb 9 at 17:21
  • @DavidGardner I did not include apt as it is at least only available for certain users. But of course, you're absolutely right. The %staff users also have god-like powers.
    – fleitner
    Feb 9 at 18:31
  • Not sure about apt local deb install. I have to check it. Ubuntu sometimes is surprising, just like letting users to browse other user home directories. see: apt can't install local deb package
    – hute37
    Feb 13 at 12:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .