![/boot/grub/grub.cfg 对普通用户而言是读保护的。为什么?](https://linux22.com/image/230076/%2Fboot%2Fgrub%2Fgrub.cfg%20%E5%AF%B9%E6%99%AE%E9%80%9A%E7%94%A8%E6%88%B7%E8%80%8C%E8%A8%80%E6%98%AF%E8%AF%BB%E4%BF%9D%E6%8A%A4%E7%9A%84%E3%80%82%E4%B8%BA%E4%BB%80%E4%B9%88%EF%BC%9F.png)
我想知道为什么该文件/boot/grub/grub.cfg
被读保护。我唯一想到的是,如果我将 grub 与 passwd 一起使用,它可以包含密码的哈希值。
然而,我没有使用该功能,因此我认为向全世界(或者至少是我的用户)提供对它的读取访问权限不会成为问题。我希望能够在没有 sudo 的情况下阅读它,既可以简化我的脚本,又可以避免处理超级用户权限。
实际上,没有人会以这种方式攻击我的个人电脑,但我想坚持良好的安全实践。
答案1
我刚刚在两种不同版本的 Linux 上检查了该文件,并且该文件都没有受到读保护。你没有提到你正在使用什么操作系统,所以我无法比较。
至少其中一种风格将密码哈希分离到一个单独的文件中,可能是专门这样 grub.cfg 没有它并且可以让世界可读。
除了建议的密码哈希之外,该文件还包含有关其他(可引导)分区内容的信息,这些信息对于非 root 用户来说可能无法读取,但此类信息可能不是很秘密,并且可能可以从以下输出中猜测出来:无论如何,lsblk(没有特权)。
因此,除了偏执或保护可能存在或不存在的散列密码的简单设计之外,我看不出 grub.cfg 不可读的原因。
答案2
看来您对机密性和密码的猜测是正确的:响应关于此问题的 CVE 报告,
自 2021 年起在上游umask 现在设置为077
创建输出文件之前。这是否有用取决于您的观点,我想:我想最好还是谨慎行事,但是嗯。