gVisor 如何保护主机免受脏牛 PoC 侵害？

Question

我正在尝试弄清楚 gVisor 如何防止脏牛漏洞 PoC。所以我在 gVisor 中的哨兵中读取了代码，看起来哨兵中的 madvise() 已锁定，因此哨兵可以避免竞争条件。在 pkg/sentry/mm/syscalls.go 中// Decommit implements the semantics of Linux's madvise(MADV_DONTNEED).func (mm *MemoryManager) Decommit(addr usermem.Addr, length uint64) error {...mm.mappingMu.RLock()defer mm.mappingMu.RUnlock()mm.activeMu.Lock()defer mm.activeMu.Unlock()...但我预计 gVisor 避免了脏牛漏洞会有结构性原因。所以我看了gVisor的几个视频和文档，但它们只是证明了gVisor可以防止写入只读文件的情况。可悲的是，我找不到其他原因来说明他们如何保护只读文件免受这些视频中的利用代码的影响。这是否意味着如果哨兵在同一点也有竞争条件，就会像普通码头工人一样发生同样的问题？如果是这样，Sentry 将尝试以 root 身份写入文件，我认为也会出现同样的问题。还是有我错过的更根本的原因？

Answer 1

来自 gVisor 邮件列表：

gVisor 确实对内存管理器进行锁定，以避免 DirtyCow 竞争条件。然而，除了良好的编码实践和测试之外，gVisor 的 Sentry 没有任何基本的东西可以保护它免受潜在有害的竞争条件的影响。

gVisor更根本的保护实际上是Sentry与主机有两层隔离。它作为用户空间进程在锁定的 Linux 容器中运行。因此，即使攻击者发现了一个允许他们在 Sentry 中执行代码的错误，攻击者也需要在 Linux 容器中可用的小型 Linux 攻击面中找到一个独立的错误。这种保护适用于许多类型的安全问题，而不仅仅是 DirtyCow。