我试图弄清楚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可以防止在只读文件上写入的情况。
遗憾的是，我找不到其他原因来说明它们如何保护只读文件免受这些视频中的漏洞利用代码的攻击。
如果哨兵在同一地点也有比赛条件，是否意味着会像普通 docker 一样发生同样的问题？
如果是这样，Sentry将尝试以根用户身份写入文件，并且我认为也会发生同样的问题。
还是我错过了更根本的原因？
最佳答案
从gVisor邮件列表中:
gVisor does do locking on the memory manager in order to avoid the DirtyCow race condition. However, there is nothing fundamental about gVisor's Sentry that protects it from potentially harmful race conditions besides good coding practices and testing.
gVisor's more fundamental protection is in fact that the Sentry has two layers of isolation from the host. It runs as a user-space process in a locked down Linux container. So even IF an attacker finds a bug that allows them to execute code in the Sentry, the attacker would need an independent bug in the small Linux attack surface that is available in the Linux container. This protection applies to many types of security issues and not just DirtyCow.
-https://groups.google.com/d/msg/gvisor-users/ze-6LpPoDcQ/Y1jScf32CQAJ
关于docker - gVisor如何保护主机免受脏牛PoC的侵害？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58382208/