如何使用 dpkg-statoverride 强化 su?

如何使用 dpkg-statoverride 强化 su?

我正在阅读 Ubuntu 14 强化指南,这是建议之一:

确保只有 sudo 组中的用户才能运行 su 命令以充当(或成为)root 用户,这通常看起来是一个明智的想法:

dpkg-statoverride --更新 --添加根 sudo 4750
/bin/su

我查了一下dpkg-statoverride命令,但我仍然无法弄清楚上面的命令到底在做什么?

这似乎暗示 Ubuntu 14 默认情况下允许任何人使用 sudo。为了测试,我创建了一个新用户,以该用户身份登录,尝试使用 sudo,但失败了——这很好。

那么上述建议的目的是什么呢?

答案1

目的是防止普通用户运行su命令(su与sudo类似,不同的是sudo执行一个命令,su以新用户身份启动一个新会话,一直持续到该用户运行exit)

su 的默认模式是 4755 或 rwsr-xr-x,“s”表示该命令是 set-UID(这意味着它始终以拥有该命令的用户身份运行,而不是以碰巧执行该命令的用户身份运行)。在这种情况下,su 由 root 拥有,因此它始终以 root 权限运行)

su 有自己的安全措施,以确保执行它的用户有权成为另一个用户(通常通过询问其他用户的密码),但可以想象,su 中可能存在安全漏洞,允许攻击者以某种方式说服它在未经授权的情况下做其他事情。

通过将模式更改为 4750,它可以防止普通用户(root 以外的用户和 sudo 组中的用户)首先读取或执行它,因此攻击者需要更改该文件的所有权,或者更改文件的模式,或者在他们尝试利用 su 中的这个理论上的漏洞之前更改自己的有效 UID/GID。

dpkg-statoverride 命令在这种情况下很有用,因为它指示包管理器使用该文件的所有权/模式值,即使它被更新的版本替换(即通过 apt 升级)。换句话说,它比 chown 和 chmod 更持久。

以下是我针对此实例推荐的通用策略:每当我在 Linux/UNIX 计算机上调整 su/sudo 或任何身份验证组件的配置时,我都会打开另一个到该服务器的 ssh/putty 会话并以以下身份登录root 用户,只需在另一个窗口中保持该会话打开即可。这样,如果我确实搞砸了一些事情并将自己锁在门外,我已经获得了一个登录会话,可以在其中修复我损坏的任何内容。

答案2

根据您的用户,这可能是好主意,也可能是坏主意。

普通用户可以使用该su命令登录任何其他帐户,而不仅仅是超级用户的帐户,前提是他们知道该帐户的密码。

这很有用,例如,当两个用户在一个项目上进行合作时,其中一个用户(用户 A)已登录,并且他们需要读取只有另一个用户(用户 B)可以访问的文件。简单地运行

su -c 'cat /home/userB/file' userB >file

可用于将文件复制到登录用户的主目录,但这只有在允许 userA 运行该su命令的情况下才有可能。

在 PostgreSQL 数据库服务器上,数据库管理员通常可以切换到用户来postgres执行一些在数据库服务器运行时无法执行的维护任务;为此,他们需要能够运行su - postgres

同样的注意事项也适用于该sudo命令(它与该命令不同并且更复杂su- 它只是默认配置,使该命令主要对组有用sudoers,因为该组被允许以 运行任何命令root。但是,如果您添加任何自定义规则,例如允许任何用户不带参数运行updatedb,则sudoers组外的用户需要执行权限sudo

另外,不仅有susetuid——还有

  • sg(如果设置了群组密码,则允许临时加入群组)
  • passwd(允许更改密码)
  • chfn(允许更改用户信息)
  • chsh(允许更改默认外壳)

和其他几个。这些工具与命令共享大量代码su,因此单独更改 的模式/bin/su不会给您带来太多好处,并且更改所有工具的模式肯定会惹恼您的用户,特别是在passwd.

答案3

在强化服务器上​​,您需要尽可能少的 setuid/setgid 二进制文件,尤其是可以由不需要特定工具的用户帐户运行的二进制文件,因为一个简单的原因:

您并不完全相信这些工具可以监管某人使用它们的行为。安全研究人员和攻击者经常发现并积极寻找此类程序或其依赖项中允许用户规避此类监管的错误。配置错误(su 行为取决于 PAM 库配置)可能会导致相同的问题。因此,给定(服务或用户)帐户可以运行的每个 setuid/setgid 二进制文件都是获得不需要的 root 访问权限的潜在媒介。

虽然此类软件中的已知问题通常会导致补丁/更新快速可用,但被迫快速安装它们可能会导致中断 - 并且某些漏洞可能不是每个人都知道,包括供应商。

因此,为了尽量减少解决紧急问题的可能性,这样做是有意义的https://stackoverflow.com/questions/2189976/find-suid-and-gid-files-under-root,然后研究其中哪些可以消除(如果您正在运行专用服务器并且知道自己在做什么,则大多数情况下),最好使用包管理系统支持的 dpkg-statoverride 等方法来保持此类更改永久。

在旧式 NFS 的特定设置中限制对“su”的访问还有另一个原因 - 您可能出于本质上的政治原因,限制 root 帐户(某些用户可能再次出于政治原因而获得该帐户。尽管如此,这是不好的做法) su 很简单,因为它绕过了 NFS 挂载的 root_squash 标志。

相关内容