Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "how to configure sudo in Linux system". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Many companies' Linux systems use sudo to configure superuser permissions that ordinary users can execute. One is to provide system administrators with more secure operating systems, and the other is to provide developers with a controllable scope of permissions. Let's take a look at the sudo configuration files that are common in our systems.

The code is as follows:

Admin ALL= (ALL) NOPASSWD: / app/nginx/sbin/nginx

This configuration file shows that admin users can call root permissions to start nginx through sudo. I believe this is also one of the functions that often use sudo, because if nginx starts port 80, ordinary users cannot start it, because the system restricts port snooping below 1024 and only root permissions can operate. Most of the problems occur in the nginx executable file in this sbin directory. Because since we want to hand over the administrative rights of nginx to the ordinary user admin, most of the cases are that all the users and groups of nginx's file permissions belong to admin, as shown below.

The code is as follows:

[admin@localhost sbin] $ll

Total dosage 3004-rwxr-xr-x 1 admin admin 3066035 Sep 10 2014 nginx

But if the nginx file under the sbin directory is also an admin user, and the file is still in the sudo permission configuration, then the problem arises. Admin users can turn any system command copy into a nginx file, and here we should know how big the potential risk is. As long as any command file admin user has read-only permission, you can turn the file into nginx and execute the command as root at will. Because sudo only cares about the file name, but not the file content itself, if the admin user needs to raise the rights to the root user, it is also very simple. Just copy the system's vi command to the sbin directory and rename it to nginx. When the file is replaced, the nginx file becomes the system's vi command. If the admin user runs sudo nginx at this time, he or she will perform the vi action with the permission of the root user. For example, when a user executes sudo nginx / etc/sudoers, he can edit the file with his root identity, thus opening himself a NO PASSWORD ALL permission. As long as you save the sudo configuration file and execute sudo su, you can easily switch to the root permission, and then restore the replaced nginx file. At this time, you can easily leave the system back door with root permission, and at the same time clear the operation record to complete the whole operation without leaving a trace. Here's a summary of the steps needed to elevate admin rights.

[admin@localhost ~] $sudo-l user admin can run the following command on this host:

The code is as follows:

(ALL) NOPASSWD: / app/nginx/sbin/nginx

[admin@localhost ~] $which vi

/ bin/vi

[admin@localhost ~] $cp / bin/vi / app/nginx/sbin/nginx

[admin@localhost ~] $sudo / app/nginx/sbin/nginx / etc/sudoers / / Note that the root permission vi has been called to edit the sudoers file.

[admin@localhost ~] $sudo-l user admin can run the following command on this host:

(ALL) NOPASSWD: ALL

[admin@localhost ~] $sudo su-root

[root@localhost ~] # / / the user successfully switched to root permissions

To avoid such a problem is actually very simple, that is, change the permissions of the files we need to execute to root, so that ordinary users have no way to rewrite this file with copy, because he no longer has the right to operate on the file, thus avoiding the risk of raising rights.

Finally, I would like to mention the process of discovering this configuration problem. When I was in charge of operation and maintenance a long time ago, Party A was still in a traditional Internet enterprise. Party A had very strict control over permissions, providing only ordinary user rights for system operators. If ordinary users need to operate apache or nginx, they need to configure sudo, because the process of applying for root permissions is very complicated. This method was found in a very urgent system fault handling, and the sudo executable file at that time had the problem that the rights belonged to, and the rights were finally raised successfully, but this method still does not encourage people to do it, ha. If such problems are found in the production system, they should be updated and repaired in time to avoid more problems caused by permission leakage.

This is the end of the content of "how to configure sudo in Linux system". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.