fstab中的nodev和nosuid的说明


44

当有人描述如何安装tmpfs或ramfs时,我经常在网上看到这两个选项。通常也与noexec一起使用,但是我对nodev和nosuid特别感兴趣。我基本上讨厌在没有真正理解的情况下盲目重复别人的建议。而且由于我在网上仅看到有关此内容的复制/粘贴说明,因此请在此处提出。

这来自文档:
nodev-不要解释文件系统上的块特殊设备。
nosuid-阻止suid和sgid位的操作。

但是,我想提出一个实用的解释,如果我不考虑这两个因素,将会发生什么。假设我已经配置了tmpfs或ramfs(没有设置这两个选项),系统上的特定(非root)用户可以访问(读+写)。该用户可以采取什么措施来损害系统?排除在使用ramfs时消耗所有可用系统内存的情况


1
这是一个很好的回答你的问题: unix.stackexchange.com/questions/188601/...
— 椭圆观点

Answers:


36

您不必一定要盲目地遵循此规则。但是,针对更注重安全性的情况的理由如下。

  • nodev挂载选项指定文件系统不能包含特殊设备:这是安全预防措施。您不希望像这样的用户可以在世界范围内访问的文件系统具有创建字符设备或访问随机设备硬件的潜力。

  • nosuid mount选项指定文件系统不能包含已设置的用户ID文件。防止在可全局写入的文件系统上执行setuid二进制文件是有道理的,因为那里存在根升级或其他麻烦的风险。

出于价值考虑,我不经常使用这些参数……仅在具有其他合规性考虑因素的面向公众的系统上使用。


1
我实际上有一个面向公众的系统,因为软件是在暴露于网络的那个帐户下运行的。所以我想知道这里的假设情景。如果有人通过某个漏洞获得外壳程序访问权限怎么办。当然,他还有其他事情可以提升权利,但我想将其最小化。因此,我想知道,例如suid,无论文件系统是否允许,用户仍然无法更改该标志。那么nosuid选项是否只能防止意外配置不良的软件(由根用户执行)?还是用户可以单独利用它?
— 伊万·科瓦切维奇

1
@IvanKovacevic您不必使用建议的文件系统挂载选项。它们在那里是为了减少攻击向量。但是,检查假设情景可能超出了此问题的范围。
— ewwhite

3
@ewwhite:有关nosuidsetuid位是否被忽略?(而不是The nosuid mount option specifies that the filesystem cannot contain set userid files)
— user2284570'1
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.