使用sudo还是su？其中的安全隐患要如何掌控？

lsstarboy

获奖名单已公布：http://bbs.chinaunix.net/thread-4183940-1-1.html

话题背景
sudo是一个非常好用、非常普及的程序，广泛存在于许多Linux教程中，但是在FreeBSD的基本系统(BASE)中，却没有使用这个OpenBSD的小工具，比较令人费解。对此您有什么高见吗？
针对网上的一些资料，以及几个关于sudo的讨论，总结了一下sudo的优缺点：

一、使用sudo的理由：
　　1、使用sudo，没有必要知道root密码，甚至可以给root设置一个非常长的密码，甚至有的人说可以不让root登录，从某一角度来说，会使系统更安全；
　　2、sudo可以记录“一切”命令，给系统的追查带来便利；
　　3、sudo可以限制某些程序，相当于给系统多了一层保障；
　　4、sudo可以在某些情况下，自动执行运行指定的命令，给脚本系统带来便利；
　　5、如果一个系统中有多个人使用root权限，如果某一位离职，只重置这位员工的密码即可。反观使用su的情况，如果修改root密码，必须同时告知所有使用root权限的员工新密码，并且su的模式中，多一个人知道，就多一份被窃的危险；
　　6、用户在输入sudo这几个字符的时候，会在潜意识中提醒这是在执行root权限，从而给系统带来一些安全感；
　　7、（FreeBSD中不存在这条）使用root登录，会被黑客暴力破解密码，因为root是一个都众所周知的帐号。

二、不使用sudo的理由
      1、sudo使用了suid标志，这个标志将使sudo运行的所有程序都有root权限，会带来很大的安全隐患；
      2、sudo穿透日志系统和审计系统，不会在系统的日志里面记录什么时候使用了root权限，也会穿过审计系统；
      3、因为sudo使用的是用户自己的密码，跟正常的登录密码相同，所以一旦用户的密码被窃取，那就等于少了一道屏障；而su使用的是root密码，即使普通密码被窃，也不会获得root密码；
      4、如果一个系统中有大量用户，那么编写一个合适的sudo规则，是一件非常困难的事情，稍不注意，就会留下安全的漏洞；
      5、sudo只能执行单一命令，对于需要cd等多条命令来说，就不是很方便；
      6、sudo sh会带来很大的隐患，起码会绕过sudo的日志系统；
      7、这条稍微有点洁癖：为什么要以张三的身份来做李四的事情？
      8、证书登录的用户，使用sudo时仍然需要输入密码，这有背于证书的本义（虽然可以通过其他手段解决掉）；

总结： 比较一致的观点是：对于系统中有多个管理员需要root权限，最好使用sudo。
     

讨论话题
1、su和sudo都可能带来哪些安全隐患？
2、你在实际工作中，是使用sudo更多一些还是su更多一些？
3、你希望sudo进入基本系统吗？
4、什么样的场合需要多人共用root密码？
5、其他你认为su和sudo的优缺点。


讨论时间
2015年06月25日--2015年07月20日


活动奖励
活动结束后将选取4名讨论精彩的童鞋，每人赠送技术图书一本作为奖励。

蛮多肉

好活动,支持.............

woxizishen

1.sudo 就相当于windows7里面那条，以系统管理员运行该程序，但仅仅是执行，但linux又有点不同的，要以系统管理员执行程序的话，首先要需要在/etc/soduers中给相关用户授权，并且linux可不只是执行程序这么简单，他可以查看普通用户无法查看系统文件等等的权限。就这点而言，我认可windows的做法

su     就相当于windows系统下的用户切换，但两者又有点不同，windows无论是管理员还是普通用户，切换到任何用户都需要使用密码，
而linux下的root却被程序猿美化到极点，无需知道普通用户的密码直接切换。相对而言，我还是认可windows的做法。


2.两者什么情况下用，对于安全性非常谨慎的童鞋，两者都有自己不利的地方，赋予了某个普通用户的sudo权限，他的权限其实并不比root小多少，你root能干的事，赋予了sudo权限的用户他绝大部分也能做，然后把超级管理员密码公之于众的作法更是扯淡的作法，出l问题，没有一个人会承认。
如果可以，一个服务器，一个管理员，一个账号，有问题，追究责任更清楚明白。没必要开放那么多特权给和这台服务器没有多大关系的人。不是每个人都那么有安全意识，特权账号越多，安全性就越低，你懂的

lsstarboy

回复 3# woxizishen

sudo 就相当于windows7里面那条，以系统管理员运行该程序，但仅仅是执行，

我对windows不太熟悉，能再详细解释一下这句吗？为什么是“仅仅是执行”？
   

forgaoqiang

嗯 这两个不是一个东西呀 更倾向于用 sudo 这里根据个人经验给大家总结下吧，希望有所帮助：

1、SU工具
①su 是一个允许用户切换到到另一个用户的工具，也就是会变成另一个用户
②su - username  其中带上 - 表示要以那个用户的环境变量来加载，如果不带username 则暗示要采用root用户
③su的结果是需要切换到的那个用户的密码的
④一旦切换成功，在exit等退出前所有的操作都是那个用户的名义进行的。

2、SUDO工具
①sudo和windows下的 runas 命令很像，也就是用户还是原来的用户，但是以指定的用户（默认是root）运行一条命令，关键是使用用户自己的密码。
②所有的规则在 /etc/sudoers 里面进行定义，可以给某些用户特定的权限
③所有的操作行为都会记录到 /var/log/secure 方便审计和日志
④RHEL 7中所有的wheel用户组默认就有权限以任意用户（包括root）运行命令，之前包括RHEL 6中都没有，要注意不要意外授权。
⑤可以使用专属编辑器 visudo 来编辑sudo规则文件。

比较高科的工具还有就是 polkit, 这个个人感觉和windows下面的 UAC（用户账户控制）很类似，高权限操作会提示用户许可（某种程度上把责任交给了用户，有点不是很负责。。。）


1、su和sudo都可能带来哪些安全隐患？
Linux系统的权限粒度比较大，root用户什么都能做，比较危险。su的话切换到root也就意味着普通用户知道root密码，sudo好一些，使用自己的密码即可完成特定授权任务。总之一旦密码泄露都能对系统造成损失，只是root损失意味着系统完全沦陷。

2、你在实际工作中，是使用sudo更多一些还是su更多一些？
说实话还是su用的多一些，虽然知道sudo更加合理，但是人懒 。。。。

3、你希望sudo进入基本系统吗？
额 不是已经进入了么 无论是Redhat还是Ubuntu发行版，都是默认内置sudo功能的，个人更倾向于无所谓的观点。

4、什么样的场合需要多人共用root密码？
开发测试服务器可以多人同时知道root密码，特别是一些虚拟化掉的设备，对于生产环境的服务器，非必要人员就不需要知道root的密码了。

5、其他你认为su和sudo的优缺点。
sudo更加安全，但是使用起来更加麻烦，总体来说就是这么个特点。

lsstarboy

回复 5# forgaoqiang


   why?  

还有-i呢？

su8610

1、su和sudo都可能带来哪些安全隐患？
在我看来这些都有隐患，当然最大的隐患就是让用户取得root权限，可以为所欲为。所以都需要设置一定的规则来规避这些东西。比如说使用su的话，无可避免的需要多个人知道root密码，这肯定不安全。所以另外一套机制来监控谁使用su到root，然后root只会又做了些什么，这样子算是一个比较可以的监控机制。对于sudo，限制sudosudo,sudo su , shellescape等等的使用，只对某个组或者某个用户开放sudo su的权限，或者根本不开放。根据用户的需要开放对应的命令，比如说管理ID的一般就是useradd , userdel, usermod之类的命令，其他不关的一概！掉。

2、你在实际工作中，是使用sudo更多一些还是su更多一些？
其实我是使用sudo多，因为使用su非常麻烦。如果要保证su - root的安全，除了要记录谁使用su，还有root之后的操作，还需要及时修改root密码，特别是每当有人离职的时候，更是需要修改root密码，所以最好是做到每次有人logout root就修改密码。

3、你希望sudo进入基本系统吗？
在我看来sudo还是比较安全一点，可以有sudo log来记录sudo 情况，还可以限制sudo 命令的使用。

4、什么样的场合需要多人共用root密码？
应该没有吧。除非都是老板，觉得每次都要敲sudo 好麻烦，那就都使用su 吧

5、其他你认为su和sudo的优缺点。
su明显方便一点，但是sudo会更加便于管理和监控

tangye

很好的讨论。认真学习。

蛮多肉

嗯 这两个不是一个东西呀 更倾向于用 sudo -s 命令 嘿嘿 功能和su一样

   

   why?  

还有-i呢？

    The major difference between sudo -i and sudo -s is:

    sudo -i gives you the root environment, i.e. your ~/.cshrc is ignored.
    sudo -s gives you the user's environment, so your ~/.cshrc is respected.