The sudo configuration of the Linux system _linux shell

Here today we discuss a very funny system configuration error in Linux systems, which is sudo, and why it's funny, because if it's improperly configured, it's easy for the average user to claim root, and without a bit of technical content, System administrators think they have done the right management, in fact, if improperly configured, permissions vulnerabilities have emerged.

Many corporate Linux systems use sudo to configure the superuser privileges that ordinary users can perform, one for a more secure operating system for systems administrators, and two for developers to provide controllable scope of permissions, and here's a look at the sudo profiles that are common to our systems.

Copy Code code as follows:

Admin all= (All) nopasswd:/app/nginx/sbin/nginx

This section of the profile shows that the Admin user can invoke root right through sudo to start nginx, which is also one of the most common uses of sudo, because if the nginx starts with Port 80, the average user cannot start. Because the system limits 1024 of the following port listening only root permission to operate, most of the problems appear in the Sbin directory on the nginx executable file, because we want to nginx administrative rights to the normal user admin, In most cases, the user and group of all file permissions for Nginx are also admin, as shown below.

Copy Code code as follows:

[Admin@localhost sbin]$ LL
Total dosage 3004-rwxr-xr-x 1 Admin admin 3066035 September 2014 nginx

However, if the Nginx file permissions in the Sbin directory are also admin users, and the file is still in the sudo permission configuration, then the problem comes, admin users can change the system arbitrary command copy come to Nginx file, here you should know the potential risk is how much, As long as any command file Admin user has read-only permission, you can turn the file into a nginx and arbitrarily execute the command as root, because sudo only cares about the executable file name, not the file content itself, if the admin user needs to be right to root under the user is very simple, As long as the system's VI command copy to the Sbin directory and rename the Nginx, when the file is replaced, the Nginx file becomes the system's VI command, if the admin users run sudo nginx at this time is the root of the user's permissions to perform the VI action, For example, when a user executes sudo nginx/etc/sudoers, he can edit the file as root to give himself the right to open a no PASSWORD all, as long as the sudo configuration file is saved, and the sudo su- You can easily switch to root permissions to come, and then replaced by the Nginx file recovery, at this time with root permissions can easily leave the system back door, while emptying the Operation Records, complete the operation without leaving traces, the following to summarize the admin right to take several steps required.

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

Copy Code code 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 this is already the call root permission vi edit 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 ~]#//user successfully switched to root permission

To avoid such a problem occurs is also very simple, that is, we need to execute the file to root can be changed, so that ordinary users can not use the Copy method to rewrite the file, because he has no permission to operate the file, and thus evade the right to raise the risk.

Finally mention the discovery of this configuration problem, in the early start of the operation of the work, at that time or in a traditional Internet enterprise, party A is very strict control of the rights, for system operators to provide only ordinary user rights, If the ordinary user needs to operate Apache or NGINX, etc. need to configure sudo, because the process of requesting root permission is very cumbersome, in a very urgent system fault handling found this method, and the sudo executable file on the existence of permissions to the problem, the ultimate right to claim success, But this method still does not encourage everybody to do ha, if in the production system found that such a problem, should be updated in a timely manner to avoid more problems caused by permission leakage.