For example: run some commands like mount, halt, su, or edit some system configuration files, like /etc/mtab, /etc /samba/smb.conf, etc. In this way, it not only reduces the number of root user logins and management time, but also improves system security.
1. Characteristics of sudo
The role played by sudo dictates that it must be extra cautious in terms of security, otherwise illegal users will seize root privileges. At the same time, it must also take into account ease of use so that system administrators can use it more efficiently and conveniently. The goal of sudo's designers was to give users as few permissions as possible while still allowing them to complete their work. Therefore, sudo
has the following characteristics:
# 1. sudo can restrict specified users from running certain commands on specified hosts.
# 2. sudo can provide logs, faithfully record what each user has done using sudo, and can transmit the logs to the central host or log server.
# 3. sudo provides configuration files for system administrators, allowing system administrators to centrally manage user permissions and hosts. Its default storage location is /etc/sudoers.
# 4.sudo uses timestamp files to complete a system similar to "ticket checking". When the user executes sudo and enters the password, the user obtains a "ticket" with a default survival period of 5 minutes (the default value can be changed during compilation). After the timeout, the user must re-enter the password.
2. sudo command
The sudo program itself is a binary file with the suid bit set. We can check its permissions:
Copy code The code is as follows:
$ls -l /usr/bin/sudo
---s-- x--x 2 root root 106832 02-12 17:41 /usr/bin/sudo
Its owner is root, so every user can execute the program like root. A program with suid set can give the user the owner's euid when running. This is why programs that set suid must be written carefully. But setting the suid of a command file and running it with sudo are different concepts, and they play different roles.
Sudo configurations are recorded in the /etc/sudoers file, which we will explain in detail below. Configuration files specify which users can execute which commands. To use sudo, the user must provide a specific username and password. Note: sudo requires not the password of the target user, but the password of the user executing sudo. If a user who is not in sudoers executes a command through sudo, sudo will report this event to the administrator. Users can use sudo -v to check whether they are among sudoers. If so, it can also update the time on your "ticket"; if not, it will prompt you but not notify the administrator.
The sudo command format is as follows:
Copy code The code is as follows:
sudo -k -l -v -h -k -l -vsudo [ -hpsb] [-a auth_type] [-c class-] [-p prompt] [-u username#uid] {-e file [...] -i -s command}
Let's take a look at some other commonly used parameters of sudo:
Options Meaning Function
sudo-hhelp lists the usage methods and exits.
sudo-vversion displays version information and exits.
sudo-llist lists the commands that the current user can execute. Only users in sudoers can use this option.
sudo-uusername#uiduser executes the command as the specified user. The following users are other than root, and can be user names or #uid.
sudo-kkill clears the time on the "admission ticket" and requires you to enter the password the next time you use sudo.
sudo-ksurekill is similar to -k, but it also tears the "entry ticket", that is, deletes the timestamp file.
sudo-bcommandbackground executes the specified command in the background.
sudo-ppromptcommandprompt can change the password prompt, where %u will be replaced by the user account name, and %h will display the host name. Very user-friendly design.
sudo-efileedit does not execute a command, but modifies files, which is equivalent to the command sudoedit.
There are also some less commonly used parameters, which can be found in the man page sudo(8).
3. Configure sudo
Configuring sudo must be by editing the /etc/sudoers file, and only super users can modify it, and must also be edited using visudo. There are two reasons why visudo is used. One is that it can prevent
two users from modifying it at the same time; the other is that it can also perform limited syntax checking. So, even if you are the only super user, you'd better use visudo to check the syntax.
Visudo defaults to opening the configuration file in vi and using vi to modify the file. We can modify this default item at compile time. visudo will not save configuration files with syntax errors without authorization. It will prompt you with the problems and ask how to deal with them, like:
Copy code The code is as follows:
>>>sudoersfile:syntaxerror,line22<<
At this point we have three options: type "e" to re-edit, type "x" to not Save and exit. Type "q" to exit and save. If q is selected, sudo will not run again until the error is corrected.
Now, let’s take a look at the mysterious configuration file and learn how to write it. Let's start with a simple example: let user foobar execute all root-executable commands through sudo. Open the configuration file with visudo as root, you can see lines similar to the following:
Copy code The code is as follows:
#runasaliasspecification
#userprivilegespecificationrootall=(all )all
We will understand at a glance that root has all permissions. Just follow the existing root example. We add a line below (it is best to use tab as a blank):
Copy code The code is as follows:
foobarall=(all)all
After saving and exiting, switch to the foobar user, we use Its identity executes the command:
Copy code The code is as follows:
[foobar@localhost~]$ls/root
ls:/root: Insufficient permissions
[foobar@localhost~]$sudols/root
password:
anaconda-ks.cfgdesktopinstall.loginstall.log.syslog
Okay, let’s restrict foobar’s rights. Don't let him do whatever he wants. For example, if we just want him to use ls and ifconfig like root, change that line to:
Copy the code The code is as follows:
foobarlocalhost=/sbin/ifconfig, /bin/ls
Execute the command again:
Copy the code The code is as follows:
[foobar@localhost~]$ sudohead-5/etc/shadow
password:
sorry,userfoobarisnotallowedtoexecute'/usr/bin/head-5/etc/shadow'asrootonlocalhost.localdomain.
[foobar@localhost~]$sudo/sbin/ ifconfigeth0linkencap:ethernethwaddr00:14:85:ec:e9:9b...
Now let us take a look at what those three all mean. The first all refers to the host in the network. We later changed it to the host name. It indicates that
foobar can execute subsequent commands on this host. The all in the second bracket refers to the target user, that is, who is the identity to execute the command. The last
all of course refers to the command name. For example, if we want user foobar to execute the kill command as jimmy or rene on the Linux host, write the configuration file like this:
foobarlinux=(jimmy,rene)/bin/kill
But there is still A question, should foobar be executed as jimmy or rene? At this time we should think of sudo-u, which is used exactly at this time. foobar can use sudo-ujimmykillpid or sudo-urenekillpid, but this is very troublesome. In fact, we don't need to add -u every time, just set rene or jimmy as the default target user. Add another line above:
defaults:foobarrunas_default=rene
defaults. If there is a colon after it, it is the default for subsequent users. If there is not, it is the default for all users. Just like the line that comes with the configuration file:
defaultsenv_reset
Another problem is that many times, we are already logged in, and it is cumbersome to enter the password every time we use sudo. Can we stop entering passwords? Of course, we can modify the configuration file like this:
foobarlocalhost=nopasswd:/bin/cat,/bin/ls
Let’s sudo again:
Copy the code The code is as follows:
[foobar@localhost~]$sudols/rootanaconda-ks.cfgdesktopinstall.log
install.log.syslog
Of course, you can also say "Some commands cannot be run as user foobar" by using the ! operator, but this is not a good idea. Because using the ! operator to "eliminate" some commands from all generally has no effect, a user can copy that command to another place, change its name, and then run it.
4. Logs and Security
sudo is very considerate for security. It can not only record logs, but also report to the system administrator when necessary. However, sudo's logging function is not automatic and must be enabled by the administrator. Do this:
Copy code The code is as follows:
#touch/var/log/sudo
#vi/etc/syslog.conf
Add a line at the end of syslog.conf (must be separated by tabs) and save:
local2.debug/var/log/sudo
Restart the log daemon process,
psauxgrepsyslogd
Fill in the obtained pid of the syslogd process (the second column of the output is the pid) as follows:
kill–huppid
In this way, sudo can write logs:
Copy code The code is as follows:
[foobar@localhost~]$sudols/rootanaconda-ks.cfg
desktopinstall.log
install.log. syslog
$cat/var/log/sudojul2822:52:54localhostsudo:foobar:
tty=pts/1;pwd=/home/foobar;user=root;command=/bin/ls/root
However, there is a small "flaw", the sudo log is not very faithful:
Copy the code The code is as follows:
[foobar @localhost~]$sudocat/etc/shadow>/dev/null
[foobar@localhost~]$
cat/var/log/sudo...jul2823:10:24localhostsudo:foobar:tty=pts/ 1;
pwd=/home/foobar;user=root;command=/bin/cat/etc/shadow
The redirection is not logged! Why? Because the shell has completed the redirection before the command is run, sudo does not see the redirection at all. This also has an advantage, the following methods will not succeed:
Copy code The code is as follows:
[foobar@localhost~]$sudols/root>/etc/shadowbash:/etc/shadow: Insufficient permissions
sudo has its own way to protect security. Execute sudo
-v as root to check the sudo settings. Because of security issues, some environment variables are not passed to the command after sudo, or are passed after being checked, such as: path, home,
shell, etc. Of course, you can also configure these environment variables through sudoers.
The above is the detailed content of How to use sudo command in linux system. For more information, please follow other related articles on the PHP Chinese website!