Rootfs权限设计

Question

听起来您已经知道足够的知识来选择/home/user1或等效的权限设计。你问的是关于休息系统的。这里已经有一些讨论，至少在相关主题上：

删除除 x 之外的所有 /etc、/usr 文件夹的组权限和其他权限。但是其他文件夹如 /usr、/var 等呢

查看系统目录上的 Unix DAC 权限并使其比提供的默认值更具限制性，这并不是一种常见策略。（用户主目录的权限除外。通常有一个配置设置）。回答如此广泛的问题的唯一方法是 -

根文件系统中的设计权限应该是什么样子

- 您应该对系统目录使用标准 DAC 权限。如果您愿意，您可以检查您最喜欢的 Linux 发行版。您还可以查看FHS，尽管可能缺少一些最近的更新。

专门进入buildroot可能使改变它们变得更加可行。但这并不意味着你“应该”！

我希望拥有安全的根组（没有额外的权限），因为usermod -aG root管理员可以由某人访问它。

不建议。你不能允许 unrestricted useradd，因为useradd -u 0，所以你无论如何都需要包装脚本或其他东西。（例如，设置 sudoers 以允许管理员以 root 身份运行包装器脚本）。更好的是，例如还提供一个包装脚本usermod，并在脚本中进行保护。然后您也可以防止攻击其他非根“系统”组（守护程序帐户）。

“普通用户”（www-data 旁边）可以使用 ssh 登录。

看起来您正在尝试运行一个安全的多用户类 Unix 系统。这是问题中最重要的部分。

这个普遍问题太广泛了，无法在这里询问并获得明确的答案。

如果用户完全不值得信任，诚实的答案是你不能。有各种权衡、策略和战术。

这个问题实际上并不是特定于“嵌入式设备，板载 busybox（buildroot 环境）”。但这可能会缩小您可以轻松使用的策略范围。

具体来说，请注意使用 buildroot 将使其成为很多与 Debian Linux 等标准二进制发行版相比，实施安全更新需要更多工作。

在您可以查看的可能的自由软件发行版中，我非常怀疑 buildroot 的目标是高度安全的多用户 Linux 系统:-)。（在大学和一些类似环境中使用的多用户网络服务器，或多用户 PC）。

大多数大型组织都有相似的内部多用户系统的问题。但他们使用的最简单的方法是不运行任何一个大型多用户 Unix（或 Windows:-) 实例，用户实际上可以在其上运行程序！

这常见的像这样的情况实际上是您拥有可供不同员工使用的台式电脑（“办公桌轮用制”，或者只是多个班次）。这里的一些常见控件是 Microsoft 业务模型（“组策略”）或更广泛的 Windows 生态系统的关键部分，有些控件不能作为免费软件等效项提供。

最强大的控件之一是“应用程序白名单”。为用户提供完整的编程/脚本环境（如 Unix shell）是相对较高的风险。通常不需要它。（并且系统绝对可以被设计为拒绝对它们的访问）。

我害怕 busybox 二进制文件，因为它打开了 set-uid 位

一些 busybox 小程序是标准命令，需要 setuid root 才能按预期工作。这是为了安全而设计的，并得到官方支持。

config FEATURE_SUID
bool “删除大多数小程序的 SUID 状态”
默认 y
帮助

使用此选项，您可以安装属于 root 且设置了 suid 位的 busybox 二进制文件，从而使某些小程序即使在由普通用户运行时也能执行 root 级别的操作（例如，在 fstab 中安装用户挂载需要此操作）。

启用此选项后，busybox 在进入 main() 函数之前会删除不需要 root 访问权限的小程序的权限。

如果你真的很偏执，甚至不希望每个小程序的初始 busybox 代码都在 root 下运行，请构建两个包含不同小程序的 busybox 二进制文件（以及指向每个二进制文件的适当符号链接），并且仅在需要它的人。

一些需要 root 权限的小程序（需要在二进制文件上有 suid 位或由 root 运行），否则将拒绝执行：crontab、login、passwd、su、vlock、wall。

如果拥有 root 权限，小程序将使用 root 权限（通过 suid 位，或者因为由 root 运行），但仍会尝试在没有 root 权限的情况下工作：findfs、ping[6]、traceroute[6]、mount。

请注意，如果您不选择此选项，但要使 busybox suid root，则所有小程序都将在 root 下运行，这是一个巨大的安全漏洞（想想“cp /some/file /etc/passwd”）。

Answer 1