I'm trying to figure out how gVisor can prevent dirty cow vulnerability PoC.
so I read code in sentry in gVisor and it seems madvise() in sentry has locking so sentry can avoid race condition.
in 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()
...
But I'm expecting there will be a structural reason why the gVisor has avoided a dirty cow vulnerability.
So I watched several videos and documents from gVisor, but they just demonstrated that gVisor can prevent from situation which write on read-only file.
And sadly, I couldn't found other reasons that how they can protected Read-only file from exploit code in those videos.
Does it mean same problem will be occurred just like normal docker if sentry also have a race condition in same point?
if so, Sentry will try to write to file as a root, and same problem will occur I think.
Or are there more fundamental reason which I missed?
From the gVisor mailing list:
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