Delegating Privileges in Linux Using Sudo

Introduction to sudo authority delegation

• su switch identity: su –l username –c 'command'
• sudo
• From the sudo package
• man 5 sudoers
• Sudo can authorize a specified user to run certain commands on a specified host. If an unauthorized user attempts to use sudo, a prompt will appear to contact the administrator.
• Sudo can provide logs to record each user's sudo operations
• Sudo provides configuration files for system administrators, allowing them to centrally manage user permissions and hosts.
• sudo uses timestamp files to implement a "ticket checking" system, with a default lifetime of 5 minutes.
• Edit the configuration file with the visudo command, which has a syntax check function:
• visudo –c Check syntax
  visudo -f /etc/sudoers.d/test

sudo

• Configuration files: /etc/sudoers, /etc/sudoers.d/
• Timestamp file: /var/db/sudo
• Log file: /var/log/secure
• The configuration file supports the use of wildcard globs:
• ? : Any single character
  *: matches characters of any length
  [wxc ] matches one of the characters
  [!wxc] Other characters except these three characters
  \x : escape
  [[alpha]] : Alphabetic Example: /bin/ls [[alpha]]*
• There are two categories of profile rules:
• 1. Alias ​​definition: not required
  2. Authorization rules: required

sudoers

• Authorization rule format:
• User login host = (representing the user) command
• Example:
• root ALL=(ALL) ALL
• Format description:
• user: The identity of the person running the command
• host: through which hosts
  (runas): As which user
  command: which commands to run

Aliases

• Users and runas:
• username
  #uid
  %group_name
  %#gid
  user_alias|runas_alias
  
• host:
• ip or hostname
• network(/netmask)
  host_alias
  
• command:
• command name
  directory
  sudoedit
  Cmnd_Alias
  

I recently wrote a short Bash program to copy MP3 files from a USB thumb drive on one network host to another. The files are copied to a specific directory on a server I run for my volunteer organization, from where they can be downloaded and played.

My program does a few other things as well, like changing the names of the files before they are copied so that they are automatically sorted by date on the web page. It also deletes all files on the USB drive, verifying that the transfer was completed correctly. This nice little program has several options, such as -h to show help, -t for test mode, and several others.

As great as my program is, it must be run as root to perform its main function. Unfortunately, there were only a few people in this organization who were interested in managing our audio and computer systems, which left it to me to find semi-technical people and train them to log into the computers used to perform the transfers and run this little program.

It's not that I can't run the program in person, but for a variety of reasons, including travel and illness, I'm not always there. Even when I'm present, as the "lazy sysadmin" I like to let others do my work for me. Therefore, I wrote scripts to automate these tasks and used sudo to specify several users to run these scripts. Many Linux commands require the user to be root to run. This protects the system from accidental damage, such as my own stupidity, and deliberate damage by malicious users.

Do what you do well

The sudo program is a handy tool that allows me, as a system administrator with root access, to delegate responsibility for all or a few administrative tasks to other users of the computer. It allows me to perform this delegation without compromising the root password, thus maintaining a high level of security on the host.

For example, let's assume that I gave regular user "ruser" access to my Bash program "myprog", which must be run as root to perform some of its functions. First, the user logs in as ruser using his own password and then runs myprog using the following command.

myprog


The sudo program checks the /etc/sudoers file and verifies that ruser is allowed to run myprog. If this is the case, sudo requests the user to enter their password - not the root password. After ruser enters the password, the program will run. Additionally, sudo logs the fact of access to myprog with the date and time the program was run, the full command, and the user who ran it. This data has already been logged in. /var/log/security.

I find it helpful to have a log of every command sudo runs for training purposes. I can see who did what and whether they entered the command correctly.

I did this to authorize myself and another user to run a program; however, sudo can be used to do much more. It allows a sysadmin to delegate authority to manage network functions or specific services to an individual or group of trusted users. It allows delegation of these functions while preserving the security of the root password.

Configure sudoers file

As a system administrator, I can use the /etc/sudoers file to allow users or groups to access individual commands, defined groups of commands, or all commands. This flexibility is key to the power and simplicity of delegation using sudo.

I found the sudoers file very confusing at first, so below I copied and deconstructed the entire sudoers file from the host I was using it on. Hopefully, as you go through this analysis, it won't be so vague to you. As an aside, I find that the default configuration files in RedHat based distributions tend to have plenty of comments and examples to provide guidance, which makes things much simpler and reduces the need to search online.

Do not modify the sudoers file using a standard editor. Use the visudo command, as it is designed to enable any changes immediately after you save the file and exit the editor. In addition to Vi, you can also use visudo.

Let's start by analyzing this file using several aliases.

Host Alias

The Host Aliases section is used to create host groups that can be used to provide access to commands or command aliases. The basic idea is to maintain this single file for all hosts in the organization, and copy it to /etc on every host. Therefore, certain hosts (such as servers) can be configured as a group to give certain users access to specific commands, such as the ability to start and stop services such as httpd, DNS, and networking; the ability to mount file systems, and so on.

It is possible to use IP addresses instead of host names in host aliases.

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
## This file must be edited with the 'visudo' command.
Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using
## wildcards for entire domains) or IP addresses instead.
# Host_Alias ​​FILESERVERS = fs1, fs2
# Host_Alias ​​MAILSERVERS = smtp, smtp2
## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ​​ADMINS = jsmith, mikem
User_Alias ​​AUDIO = dboth, ruser
## Command Aliases
## These are groups of related commands...
## Networking
# Cmnd_Alias ​​NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
## Installation and management of software
# Cmnd_Alias ​​SOFTWARE = ​​/bin/rpm, /usr/bin/up2date, /usr/bin/yum
## Services
# Cmnd_Alias ​​SERVICES = /sbin/service, /sbin/chkconfig
## Updating the locate database
# Cmnd_Alias ​​LOCATE = /usr/bin/updatedb
## Storage
# Cmnd_Alias ​​STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount
## Delegating permissions
# Cmnd_Alias ​​DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp
## Processes
# Cmnd_Alias ​​PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall
## Drivers
# Cmnd_Alias ​​DRIVERS = /sbin/modprobe
# Defaults specification
# Refuse to run if unable to disable echo on the tty.
Defaults visiblepw
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = sbin:bin:usr\sbin:usr\bin:usr\local\bin
## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
## user MACHINE=COMMANDS
## The COMMANDS section may have other options added to it.
## Allow root to run any commands anywhere
root =ALL ALL
## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS
## Allows people in group wheel to run all commands
wheel =ALL ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
## Allows members of the users group to mount and unmount the
##cdrom as root
# %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
## Allows members of the users group to shutdown this system
# %users localhost=/sbin/shutdown -h now
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
############################################################
# Added by David Both to provide limited access to myprog #
############################################################
AUDIO guest1=usrlocalbinmyprog

Default sudoers file, changes are in bold.

User alias

User alias configuration allows root to sort users into alias groups so that the entire group has access to specific root capabilities. This is the part where I added a line. User_Alias ​​AUDIO = dboth, ruser, which defines the alias audio and assigns two users to the alias.

As described in sudoers file, one can simply use the /etc/groups file instead of an alias. If you already have a group defined there that suits your needs, such as "audio", use that group name preceded by a % sign like this: %audio when assigning the commands that will be available to the group later in the sudoers file.

Command Aliases

At the bottom of the sudoers file is a command aliases section. These aliases are lists of related commands, such as network commands or commands required to install updates or new RPM packages. These aliases allow a sysadmin to easily allow access to groups of commands.

There are a number of aliases already set up in this section that make it easy to delegate access to specific types of commands.

Environment Defaults

The next section sets some default environment variables. The most interesting item in this section is the !visiblepw line, which prevents sudo from running if the user environment is set up to show passwords. This is a safety precaution that should not be overridden.

Command Section

The commands section is the main part of the sudoers file. By adding enough entries here, everything you need to do can be accomplished without all the aliases. The pseudonym just makes things a lot easier.

This section uses the aliases you have already defined to tell sudo who can do what on which host. The examples are self-explanatory when you understand the syntax in this section. Let's look at the syntax we found in the commands section.

ruser =ALL ALL


This means that ruser can run any program on any host as any user.

This is the general entry for our user, ruser. The first ALL in the line indicates that this rule applies to all hosts. The second ALL allows ruser to run commands like any other user. By default, commands are run as the root user, but ruser can specify on the sudo command line that the program run as another user. The last ALL means that ruser can run all commands without restriction. This will effectively make ruser root.

Note that there is one entry for root as shown below. This gives the root user full access to all commands on all hosts.

root =ALL ALL

This means that root can run any program on any host as any user.

To try this, I commented out the line and, as root, tried running chown without sudo. That actually worked - it really surprised me. Then I chown with sudo it fails with the message, "root is not in the sudoers file and this event will be reported." This means that root can run everything as root but not when using the sudo command. This will prevent the root user from running sudo commands as other users, but there are many ways for root to get around this restriction.

The code below is what I added to control access to myprog. It specifies that users listed in the audio group, as defined at the top of the sudoers file, can access only one program, myprog, on one host, namely guest 1.

AUDIO guest1=usrlocalbinmyprog

Allow users in the audio group to access myprog on the host user1.

Note that the syntax of the above line only specifies the hosts and programs that are allowed this access. It does not specify that the user can run programs as other users.

Bypass Password

You can also use NOPASSWORD to allow users specified in the group audio to run myprog without entering their password. Here’s how:

AUDIO guest1=NOPASSWORD : usrlocalbinmyprog


Allow users in the audio group to access myprog on the host user1.

I didn't do that for my program because I thought that users with sudo access would have to stop and think about what they were doing, and that might help with that. I'm using the entry for my applet as an example.

wheel

The wheel specification in the command section of the sudoers file (as shown in the image below) allows all users in the "wheel" group to run all commands on any host. The wheel group is defined in the /etc/group file, and the user must be added to the group for this to work. The % sign in front of the group name means that sudo should be included in the /etc/group file.

wheel ALL = ALL ALL

Allows all users who are members of the "wheel" group, as specified in the /etc/group file, to run all commands on any host.

This is a great way to delegate full root access to multiple users without ever having to provide a root password. Simply adding a user to the wheel group gives them access to full root permissions. It also provides a way to monitor its activity through the log entries it creates. Some distributions (like Ubuntu) add the user ID to /etc/group which allows them to use the sudo command for all privileged commands.

Final Thoughts

I'm using sudo here for a very limited goal - to provide one or two users with access to a single command. I accomplish this in two lines (if you ignore my own comments). Delegating the ability to perform certain tasks to a user without root access is simple and can save you a lot of time as a system administrator. It also generates log entries that can help detect problems.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links