Sudoers policy

Summary of policy

  1. Full sudo access will not be granted.
  2. Sudo su (switch user) access will be granted to service accounts upon request.
  3. Sudo access to specific commands run as specific users is granted upon request.
  4. Sudo chmod is unnecessary because the owning user can already chmod files.
  5. Sudo chown will be granted when applied to specific directories.

Annotated policy

  1. Full sudo access will not be granted, with exceptions granted only by the Linux Engineering team.
    1. Full sudo is what is assumed when users ask for “sudo access” without any qualifiers. Users may not mean this; they might mean sudo su $SHAREDACCOUNT but this cannot be assumed. Requests should be explicit as to what user they should run as, and what commands to run.
    2. Exceptions will be granted for development/sandbox environments as approved by the Linux Engineering team.
  2. Sudo su (switch user) access will be granted to service accounts as requested through PARs and approved by the Linux Engineering team.
    1. Normal access to servers is through individual user accounts, who then switch user to a shared account to manage files and services. Some teams connect directly as a shared account which is not recommended but outside the scope of this policy.
  3. Sudo access to specific commands run as specific users is granted as requested through PARs and approved by the Linux Engineering team.
    1. Perhaps not shells are needed, but just specific commands run as a different user. Switching users to an interactive shell is normal activity.
  4. Sudo chmod is unnecessary because the owning user can already chmod files.
    1. A user should not run chmod against files that are not his because this is an unacceptable escalation of privilege.
  5. Sudo chown will be granted when applied to specific directories.
    1. If sudo chown * were to be granted, the user could take over system files and is not permissible.
    2. Permissible options involve a specific directory name, with the recursive flag.
[appdeployer ~]$ sudo chown -R appdeployer.appdeployer /opt/appdeployer/v5

The entry in sudoers:

appdeployer hostname = (root) /bin/chown -R appdeployer.appdeployer /opt/appdeployer/v5, /usr/bin/chown -R appdeployer.appdeployer /opt/appdeployer/v5

Definitions

Term Meaning
Full sudo sudo su root or any other command that uses sudo to achieve a root shell
PAR Permission access request ticket

Example sudoers

This is an example sudoers file.

# file: /etc/sudoers.d/30_db_dbas_sudo
# managed by ansible
# last updated 2018-12-10 20:11Z

User_Alias DBUSERS = %db_dbas, !db
Host_Alias DBHOSTS = l*dbr*, l*dbr*.ad.example.com, l*dbr*.ipa.example.com
Host_Alias DBHOSTS_DEV = l2*dbr*, l2*dbr*.ad.example.com, l2*dbr*.ipa.example.com
Cmnd_Alias BECOME_CMNDS = /bin/su - db, /bin/su db
Cmnd_Alias DBCMNDS = /bin/ls, /bin/ps
Cmnd_Alias DBCMNDS_DEV = ALL

# Users may switch to shared local user
Defaults:DBUSERS !authenticate
DBUSERS DBHOSTS = (root) BECOME_CMNDS
DBUSERS DBHOSTS = (db) ALL

# Local user may run these commands
Defaults: db !authenticate
db DBHOSTS = (root) DBCMNDS
db DBHOSTS_DEV = (root) DBCMNDS_DEV

Use su with ssh X-forwarding

This is a shameless ripoff of Howto use su with ssh x-forwarding [coderwall.com]

If you ssh to a server and want to do X forwarding, make sure the server allows it in /etc/ssh/sshd_config:

X11Forwarding yes

And then your ssh command should include -X, or make sure your ~/.ssh/config includes:

ForwardX11 yes

Command:

ssh -X servername

And once on the server, prepare your xauth file to be shared the other user before switching and merging it.

xauth extract /tmp/x $DISPLAY
chmod 0644 /tmp/x
su otherusername
xauth merge /tmp/x

References

Web searches

ssh x forwarding with su