为什么组可写目录被认为是不安全的？

Question

更具体地说，为什么 libslack 的守护进程认为在组可写目录中执行的文件是“不安全的”？如果您能从一般意义上解释一下为什么组可写目录被认为是不安全的，那就太好了。

抱歉，显然这太不清楚了。在 libslack 的守护进程手册页中，它指出：

-U，——不安全

允许读取不安全的配置文件并执行不安全的可执行文件。如果配置文件或可执行文件是组或世界可写的，或者位于组或世界可写的目录中（遵循符号链接），则它是不安全的。如果可执行文件是由另一个可执行文件解释的脚本，则如果解释器不安全，则认为它是不安全的。如果解释器是 /usr/bin/env（带有要在 $PATH 中搜索的命令名的参数），则该命令必须是安全的。默认情况下，daemon(1) 将拒绝读取不安全的配置文件或在由 root 运行时执行不安全的可执行文件。此选项将覆盖该行为，因此永远不应使用。

最后，它指出这个选项（不安全的选项）应该绝不显然/可以推测是出于安全考虑而被使用。

我个人似乎真的无法想象将驻留在组可写目录中的东西守护进程会有什么本质上的不安全性。

我也不明白为什么我的问题被搁置，因为对于任何真正读过它的人来说，这似乎是一个相当直接的问题，但这里试图把它写得更清楚。

为什么如果文件路径中有一个组可写的目录则被认为是不安全的？

对我来说，这更具体地涉及 libslack 的守护进程，但我已经看到多个其他软件包也将相同的情况标记为不安全，因此如果您可以提供一些信息，说明由于我运行带有不安全标志的守护进程（尽管有警告），我可能会遇到什么类型的安全问题，那就太好了。

Answer 1

来自 sendmail/Majordomo 手册：

2.4.1. 不安全的组写入的后果

如果用户对别名文件具有写入权限，则她应该是受信任的用户。通过在别名文件中添加条目（例如用于执行包装器的条目），用户可以使用 Sendmail（守护程序，或在旧版本中为 root）的权限执行任何程序。此失误将允许人们删除或更改属于守护程序的文件的权限（使用别名文件中的rm或命令）。在某种程度上，使用 smrsh 可以避免这种可能性；但是，仍然必须小心/ 目录chmod中的文件。/etc/smrsh

另一个重要的安全问题是，可以访问别名文件的用户可以使用文件重定向（a >>或>代替a |）附加或写入属于守护进程的文件。即便如此，也可以通过在文件中添加一行来限制可以通过别名文件写入的文件来弥补这一漏洞sendmail.cf。

<..>

对于include或.forward文件，命令或重定向以拥有该文件的用户身份运行。因此，如果某个文件是组可写的，则该组的成员可以以拥有该文件的用户身份执行命令。换句话说，该组中的任何用户都可以以该用户的身份执行命令。但是，由于创建该用户时没有 shell，因此不会在include该用户拥有的文件中处理命令或重定向。

4.2. 不安全的组可写目录路径的后果

例如/etc/，如果用户对某个目录具有组写入权限，则用户可以简单地移动任何文件并在其位置创建一个新文件。攻击可能类似于以下内容：

[user@system etc]$ mv aliases ...
[user@system etc]$ vi aliases

然后，用户可以创建自己的别名！但是，Sendmail 可以通过对不安全组可写路径进行安全检查来阻止这种攻击。这种攻击也适用于具有不安全路径的文件include。.forward

来源。

本手册对此进行了很好的解释，同样的逻辑也适用于许多其他软件：请记住，您正在使用多用户系统，即使您可能是该系统的唯一用户。在多用户系统中，用户需要受到保护，以免受到其他用户的侵害。