Docker gVisor如何保护主机免受脏牛PoC?

Docker gVisor如何保护主机免受脏牛PoC?,docker,security,go,race-condition,gvisor,Docker,Security,Go,Race Condition,Gvisor,我想弄清楚gVisor是如何防止脏牛病的 所以我在gVisor中阅读了sentry中的代码,sentry中的madvise()似乎有锁,所以sentry可以避免竞争条件 在pkg/sentry/mm/syscalls.go中 // Decommit implements the semantics of Linux's madvise(MADV_DONTNEED). func (mm *MemoryManager) Decommit(addr usermem.Addr, length uint6

我想弄清楚gVisor是如何防止脏牛病的

所以我在gVisor中阅读了sentry中的代码,sentry中的madvise()似乎有锁,所以sentry可以避免竞争条件

在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将尝试以根用户身份写入文件,我认为同样的问题也会发生


还是我遗漏了更基本的原因?

来自gVisor邮件列表:

gVisor在内存管理器上执行锁定,以避免DirtyCow争用情况。然而,除了良好的编码实践和测试之外,gVisor的哨兵并没有任何基本的东西可以保护它免受潜在的有害种族条件的影响

gVisor更基本的保护是哨兵与宿主之间有两层隔离。它在锁定的Linux容器中作为用户空间进程运行。因此,即使攻击者发现一个允许他们在Sentry中执行代码的bug,攻击者也需要在Linux容器中提供的小型Linux攻击面中有一个独立的bug。这种保护适用于许多类型的安全问题,而不仅仅是DirtyCow


-

这是我在写入堆栈溢出后的问题:)。但是谢谢你为我寻找答案!