str*_*ika 129 security login su sudo privileges
即使我的非特权用户受到威胁，我也希望 root 帐户安全。
在 Ubuntu 上，默认情况下您只能出于“安全原因”使用 sudo。但是，我不确定它是否比仅在文本模式控制台上使用登录更安全。如果攻击者可以以我的普通用户身份运行代码，那么可能会出错的事情太多了。例如添加别名、向我的 PATH 添加东西、设置 LD_PRELOAD 和 X11 键盘记录器等等。我能看到的唯一优势是超时，所以我永远不会忘记注销。
我对 su 也有同样的疑问，但它甚至没有时间限制。某些操作（尤其是 IO 重定向）对 su 更方便，但在安全方面这似乎更糟。
在文本模式控制台上登录似乎是最安全的。由于它是由 init 启动的，如果攻击者可以控制 PATH 或 LD_PRELOAD，那么他已经是 root。按键事件无法被 X 上运行的程序拦截。我不知道 X 上运行的程序是否可以拦截 [ctrl]+[alt]+[f1]（并打开一个看起来像控制台的全屏窗口）或它就像 Windows 上的 [ctrl]+[alt]+[del] 一样安全。除此之外，我看到的唯一问题是没有超时。
所以我错过了什么吗？为什么 Ubuntu 的人决定只允许 sudo？我可以做些什么来提高任何方法的安全性？
SSH呢？传统上 root 不能通过 SSH 登录。但是使用上述逻辑不是最安全的做法：
mat*_*tdm 113
安全始终是权衡取舍。就像众所周知的服务器位于安全的、不插电的、位于海底的服务器一样，如果根本无法访问它，那root将是最安全的。
像您描述的那样的 LD_PRELOAD 和 PATH 攻击假设攻击者已经可以访问您的帐户，或者至少可以访问您的点文件。Sudo 根本不能很好地防止这种情况——毕竟，如果他们有你的密码，那么以后就不需要尝试欺骗你了……他们sudo 现在就可以使用了。
重要的是要考虑 Sudo 最初的设计目的：在不完全放弃 root 的情况下，将特定命令（例如管理打印机的命令）委派给“子管理员”（可能是实验室的研究生）。使用 sudo 做所有事情是我现在看到的最常见的用法，但这不一定是程序要解决的问题（因此配置文件语法极其复杂）。
但是，sudo-for-unrestricted-root确实解决了另一个安全问题：root 密码的可管理性。在许多组织中，这些内容往往像糖果一样传递，写在白板上，然后永远保持不变。这留下了一个很大的漏洞，因为撤销或更改访问权限成为一个很大的生产数字。甚至跟踪哪台机器有什么密码也是一个挑战——更不用说跟踪谁知道哪个了。
请记住，大多数“网络犯罪”都来自内部。使用所描述的 root 密码情况，很难追踪谁做了什么——远程日志记录的 sudo 处理得很好。
在您的家庭系统上，我认为更多的是不必记住两个密码的方便性问题。很可能很多人只是简单地将它们设置为相同 - 或者更糟的是，最初将它们设置为相同然后让它们不同步，从而使 root 密码失效。
在SSH 中完全使用密码是危险的，因为密码嗅探木马的 ssh 守护进程在我见过的 90% 的真实系统妥协中都存在。使用 SSH 密钥要好得多，而且这也可以成为远程 root 访问的可行系统。
但是现在的问题是您已经从密码管理转移到了密钥管理，而 ssh 密钥并不是很容易管理。没有办法限制复制，如果有人复制了，他们可以尝试暴力破解密码。您可以制定策略，规定密钥必须存储在可移动设备上，并且仅在需要时才安装，但没有办法强制执行——现在您已经引入了可移动设备丢失或被盗的可能性。
最高安全性将通过一次性密钥或基于时间/计数器的加密令牌来实现。这些可以在软件中完成，但防篡改硬件甚至更好。在开源世界中，有WiKiD、YubiKey或LinOTP，当然还有专有的重量级RSA SecurID。如果您在大中型组织中，甚至是具有安全意识的小型组织中，我强烈建议您研究这些管理访问方法之一。
不过，这对于家庭来说可能有点过头了，因为在那里您没有真正的管理麻烦——只要您遵循合理的安全实践。
Gil*_*il' 32
在 su 和 sudo 之间，当您考虑单个用户时，su 更安全一些，因为找到您密码的攻击者无法立即获得 root 权限。但是攻击者只需找到本地根漏洞（相对不常见）或安装木马并等待您运行su即可。
当有多个用户时，Sudo 甚至比控制台登录更有优势。例如，如果一个系统配置了远程防篡改日志，你总是可以找出最后运行 sudo 的人（或谁的帐户被盗），但你不知道谁在控制台上输入了 root 密码。
我怀疑 Ubuntu 的决定部分是为了简单（只记住一个密码），部分是为了安全性和共享机器（企业或家庭）上的凭证分发的便利性。
Linux 没有用于身份验证的安全注意密钥或其他安全用户界面。据我所知，即使是 OpenBSD 也没有。如果您担心 root 访问，则可以完全禁用正在运行的系统的 root 访问：如果您想成为 root，则需要在引导加载程序提示符下键入一些内容。这显然不适用于所有用例。（*BSD 的安全级别是这样工作的：在高安全级别，有些事情你必须重新启动才能完成，例如降低安全级别或直接访问已安装的原始设备。）
限制一个人成为 root 的方式并不总是对安全有益。记住安全三元组的第三个成员：机密性、完整性、可用性。将自己锁定在系统之外可能会阻止您对事件做出响应。
imz*_*hev 12
安全的 OpenWall GNU/*/Linux 发行版的设计者也对su（成为 root 用户）和sudo. 您可能有兴趣阅读此主题：
...不幸的是 su 和 sudo 都有微妙但根本上的缺陷。
除了讨论 的缺陷su和其他事情之外，Solar Designer 还针对使用的一个具体原因su：
是的，“su root”过去是系统管理员的普遍智慧，而不是以 root 身份登录。那些在被问及实际上可以为这种偏好提出正当理由的少数人会提到通过这种方法实现的更好的问责制。是的，这确实是支持这种方法的一个很好的理由。但它也是唯一的。...（阅读更多）
在他们的发行版中，他们“完全摆脱了默认安装中的 SUID 根程序”（即，包括su; 并且他们没有为此使用功能）：
对于服务器，我认为人们需要重新考虑，并且在大多数情况下，禁止用户调用 su 和 sudo。与以非 root 用户和直接以 root 用户身份登录（两个单独的会话）相比，旧的“以非 root 用户身份登录，然后以 su 或 sudo 到 root 用户”系统管理员“智慧”没有增加安全性。相反，从安全的角度来看，后一种方法是唯一正确的方法：
http://www.openwall.com/lists/owl-users/2004/10/20/6
（对于多个系统管理员的问责制，系统需要支持拥有多个 root 特权帐户，就像 Owl 那样。）
（对于带有 X 的桌面，这变得更加棘手。）
你也绝对必须处理...
顺便说一句，他们将取代sulogin与msulogin允许有多个root账户设置：msulogin允许进入单用户模式时，一个在用户名也键入（并保留了“问责制”）（本信息来自于俄罗斯讨论） .
| 归档时间： |
|
| 查看次数： |
32777 次 |
| 最近记录： |