Score:2

Privilege escalation prevent root directly

in flag

I think this is going to be my first post on StackExchange side of the house. However, I know that this has to be able to be configured cause I have seen it implemented previously but I don't actually know how it's implemented.

What I'm looking to do is on RedHat 7/8 or derivative... How can I make it so that a user has to conduct the following privilege escalations:

<user> -> <user>.adm -> root

  • Users in IdM in ssh_users group can SSH to the servers from anywhere in the network(s).
  • Domain Admins in IdM cannot be used for SSH to servers and are not in the group.
  • Users who are Domain Admins must SSH to their standard user then sudo su - <user>.adm. They cannot directly get to root.
  • Users who are Domain Admins who also have root access must first sudo su - <user>.adm then they can sudo su - root
  • Not all Domain Admins have the permission to gain root escalation.

Ultimately, Domain Admins are the System Administrators with permissions relevant to maintain, troubleshoot and remediate the system. System Engineers have the permission to gain root which give them the full permissions on the system. This also goes into delegation of responsibilities where only auditing accounts <user>.isso have permissions to delete logs outside of root user. Which is ultimately what is stemming this requirement.

What I'm really looking for is documentation that would (cause I'm drawing blanks) which can point me in the right direction or Ansible roles/playbooks that functionally do this type of least privilege approach. Any help would be greatly appreciated!

paladin avatar
id flag
Allow for each user `sudo -iu <user>.adm` and allow for all adm-user `sudo -i` via `visudo`.
Maxs728 avatar
in flag
Yeah but what would the rule look like then? `%admins <hostname>, <fqdn>=(?) /bin/su - ?` I'm not sure how to put the runas-user:runas-group or the command so that they can only run `sudo su - <user>.adm`; e.g. `ssh jsmith@somehost` `sudo su - jsmith.adm`
Score:3
in flag

Users who are Domain Admins who also have root access must first sudo su - <user>.adm then they can sudo su - root

Conceptually I think that what you should want and need to achieve is:

All administrators have two personal accounts:

  1. a "regular" user account
  2. an administrator account

To gain full administrator rights on a Linux server:

  1. the admin first needs to log in with their regular user account <user>

  2. once logged on the server they escalate their privileges by logging into their personal administrator account <user>.adm

    • sudo su - <user>.adm requests the password for the <user> account, and then, with root privileges, substitutes the user to <user>.adm.
    • ^^^ That is the wrong approach IMHO
      You should want your admins to use su - <user>.adm
      That means your admin will be required to enter to their password for the <user>.adm account (rather than the password for the <user> account) to log in as <user>.adm.
      • Then, as long as your administrators don't have the same password on their adm account as on their regular account, a compromised password won't be sufficient to become root on all your servers. WIN!
      • Additionally there is no sudo policy required for their regular user account <user>. WIN!
  3. Once logged in with a personal administrator account that should then allow them to perform all actions that require root privileges.

    That requires setting up a sudo policy. There's more than enough information about that.

    My preference is using the #includedir /etc/sudoers.d mechanism included in most modern /etc/sudoers policies (the # there is not a comment!) and drop a file (that does not include a . in the file name) and set up policies that way.

    One option is to have one policy for hbruijn.adm personally i.e. /etc/sudoers.d/hbruijn_adm:

    # /etc/sudoers.d/hbruijn_adm 
    # sudo policy that allow HBruijn's admin account to perform all
    # as any user, without prompting for a password
    hbruijn.adm  ALL = NOPASSWD: ALL
    

    Alternatively when you have all adm accounts that are allowed to gain full root privileges on Linux systems belong to specific group, set up a group based policy.


Implied is that you additionally prevent that your administrators can log in directly to their adm account.

That can be, for example for SSH remote access be achieved by using a DenyUsers directive in the servers /etc/ssh/sshd_config to prevent a specific user, or users matching a pattern, from logging on:

# /etc/ssh/sshd_config
#here go defaults for all connections/users
PasswordAuthentication no
PubkeyAuthentication no
...
DenyUsers *.adm 

Alternatively use the similar DenyGroups to set up a group based policy.

Maxs728 avatar
in flag
Yeah I should have thought that through in the question but you are correct I wouldn't want to give permission to the sudo command just need `su - <user>.adm`. This is much more aligned to what I'm trying to accomplish but... maybe I was overthinking this approach. I think if I understand correctly. Use the `DenyGroups` directive in `sshd_config` or alternatively in Host-Based Access Control in IdM to deny the Domain Admins ssh. Then presumably when they access the host via the standard user they can `su - <user>.adm` which obviously they would only have their password. Or should...
Maxs728 avatar
in flag
Then by setting up the sudo policy for the Domain Admins group I can essentially define what they need to be able to do from their privileged users explicitly. Meanwhile could explicitly deny or not allow them to run `sudo su` or `sudo su - root` through the policy.
HBruijn avatar
in flag
In general the sudo approach to managing privileges is by granting as little as needed, rather than attempting to only disallow specific commands while allowing everything else. Since there are usually many methods possible to achieve a similar result an exclusion list can often be circumvented. For example granting the "innocent" right to run the `vim` editor as root can effectively unintentionally grant unlimited root privileges : see https://unix.stackexchange.com/a/181494/48232 - so never grant any privileges when you don't trust people to behave as intended
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.