The method of weight assignment using sudo in Linux is explained in detail

preface

Learn how to secure root passwords while giving trusted users access to managed network functions and specific services.

I recently wrote a short Bash program to copy MP3 files from one Web host's USB disk to another. The copied files are stored in a specific directory on a volunteer organization's server, where they can be downloaded and played.

My program also does other things, such as renaming files before copying them in order to automatically sort them by date on a web page. After verifying that the copy is complete, all files on the USB disk are also deleted. The applet has a few other options, such as -ES12en showing help, -ES13en going into test mode, and so on.

My program needs to run on root to work. However, there were few people in the organization later interested in managing audio and computer systems, which forced me to bring in the half-timers and train them to log on to the transmission computer and run the little program.

It's not that I can't run the program myself, but I'm not always there for various reasons, including being out and sick. Even when I'm there, as a "lazy sysadme," I expect someone else to do it for me. So I wrote a few scripts to automate these tasks and assign someone to run the scripts via sudo. Many Linux commands require users to run as root. sudo protects the system from accidental damage caused by ignorance at 1 hour and vandalism by malicious users.

Use sudo whenever possible

sudo is a handy tool that allows an administrator with root permissions to assign all or part of the administrative tasks to other users without having to tell them the root password, thus ensuring high host security.

Suppose I give ordinary user ruser access to my Bash program, myprog, which requires root for some of its functions. The user can then log in as ruser and run myprog with the following command.

sudo myprog

The sudo program checks the /etc/sudoers file and confirms that ruser is licensed to run myprog. If permitted, sudo will ask the user for his password -- not the root password. After ruser entered his password, the program ran. In addition, sudo records the date and time the program was run, the complete command, and who was running it. This data is recorded in /var/log/security.

I found it helpful to record every command executed with sudo during training. I can see who executed what commands and whether they lost correctly.

I delegated authority to myself and another person to run that one program; However, sudo can do much more. It allows a system administrator to delegate managed network functions or specific services to a trusted person or group of people. This allows you to protect the root password while also enabling those features.

Configure the sudoers file

As a system administrator, I use the /etc/sudoers file to set up certain users or groups of users to have access to a command, or a set of commands, or all commands. This flexibility is key to balancing functionality and simplicity when delegating with sudo.

I was initially confused by the sudoers file, so I'm going to copy and dissect the entire sudoers file on the host I'm using. I hope the analysis doesn't confuse you. I was surprised to find that the default configuration file in the Red Hat distribution is full of comments and examples to guide you on how to make changes, which makes it much easier to modify the configuration file and requires less searching on the Internet.

Instead of using the editor to modify the sudoers file, use the visudo command, which takes effect as soon as you save and exit the editor. visudo can also use editors other than Vi.

Let's start by analyzing the various aliases in the 1 file.

The host alias

Host Alias This section is used to create a group of hosts that are granted what commands or command aliases they can access. The basic idea is that the file is maintained by all hosts in the organization and then copied to /etc on each host. Some of these hosts, such as various servers, can be configured as a group to give users access to specific commands, such as start and stop HTTPD, DNS, and network services; File systems can be mounted, and so on.

You can also use the IP address instead of the host name when setting the host alias.

## 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

A user alias

User aliases allow root to group users into alias groups and assign specific root permissions by group. In this section, I added a line User_Alias AUDIO = dboth, ruser, which defines an individual name AUDIO to refer to two users.

As clarified in the sudoers file, you can also simply use the groups defined in /etc/groups without having to set the aliases yourself. If your defined group (assuming it is audio) is sufficient, assign the command to the group by adding the % sign before the group name, like this: %audio.

## 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 alias

This is followed by the alias part of the command. These aliases represent series 1 related commands, such as network-related commands, or RPM package management commands. These aliases allow a system administrator to easily assign permissions to a set of commands.

This section already has a number of aliases set up, which makes it much easier to assign permissions to certain types of commands.

## 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

Environment default

The following sections set the default environment variables. This part is the most noteworthy! visiblepw, which means that sudo is disabled when the user environment is set to display a password. This security measure should not be modified.

# 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

The command part

The command section is the body of the sudoers file. Not using aliases doesn't affect what you accomplish; aliases just make the configuration a lot easier.

This section USES the aliases defined earlier to tell sudo who can do what on which machines. Once you understand the syntax of this section, you will find the examples very intuitive. Let's look at the syntax.

ruser   ALL=(ALL) ALL

ruser can run any command as any user on any host

This is a configuration for user ruser. The first ALL in the line indicates that the rule is in effect on all hosts. The second ALL allows ruser to run commands as any other user. By default, the command runs as an root user, but ruser can specify that the program runs as another user on the sudo command line. This last ALL means that ruser can run all commands without restriction. That makes ruser essentially root.

Note that there is another configuration for root below. This allows root to run any command from sudo on any host.

root ALL=(ALL) ALL

root can run any command as any user on any host

For experiment 1, I commented out this line and tried to run chown directly as root. Surprisingly, it worked. Then I tried sudo chown and failed, with the message "Root is not the sudoers file". This incident will be reported ". This means that root can run any command directly, but not when sudo is added. This prevents root from using the sudo command to run other commands like any other user, but root has too many ways to get around this constraint.

The following line is what I added to control access to myprog. It specifies that only users in the AUDIO group defined above can use the myprog command on guest1.

AUDIO guest1=/usr/local/bin/myprog

Allows AUDIO group members to access myprog on the guest1 host

Note that the above line specifies only the host name and the program that is allowed to access and does not say that the user can run the program as another user.

Omit the password

You can also use NOPASSWORD to enable users in the AUDIO group to run myprog without a password. Like this:

AUDIO guest1=NOPASSWORD : /usr/local/bin/myprog

Allows AUDIO group members to access myprog on guest1 without entering a password

I didn't do that because I felt that users of sudo had to stop and think about what they were doing and it would be good for them. I'm just giving you an example here.

wheel

The wheel description in the commands section of the sudoers file (shown below) allows all users in the wheel group to run any command on any machine. The wheel group is defined in the /etc/group file and the user must join the group to work. The % symbol before the group name indicates that sudo should look for the group in the /etc/group file.

%wheel   ALL = (ALL) ALL

Running all "wheel" group members defined in the /etc/group file can run all commands on any host

This approach does a good job of giving multiple users full root permissions without having to provide an root password. Simply add the user to the wheel group to give them the full root capability. It also provides a way to monitor their behavior through the logs created by sudo. Some Linux distributions, such as Ubuntu, automatically add a user's ID to the wheel group in /etc/group, enabling them to run all privileged commands with the sudo command.

conclusion

I'm just trying out 1 sudo here - I'm just giving 1 to 2 users root permissions to run a single command. This is done by adding only two lines of configuration (comments aside). Delegating permission for a task to other non-ES267en users is simple and can save you a lot of time. It also generates logs to help you spot problems.

The sudoers file has many other configurations and capabilities. Check out the man manuals for sudo and sudoers for more details.