gVisor 如何保护主机免受脏牛 PoC 攻击？

Question

我正在尝试弄清楚 gVisor 如何防止脏牛漏洞 PoC。

所以我在 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 可以防止在只读文件上写入的情况。

遗憾的是，我找不到其他原因来说明他们如何保护只读文件免受那些视频中的漏洞利用代码的侵害。

如果哨兵在同一点上也有竞争条件，是否意味着会像正常情况一样出现同样的问题docker？

如果是这样，Sentry 将尝试以 root 身份写入文件，我想也会出现同样的问题。

还是我错过了更根本的原因？

Answer 1

来自 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

gVisor 如何保护主机免受脏牛 PoC 攻击？

How gVisor can protect host from dirty cow PoC?

security

go

race-condition

docker

gvisor