8 ms·

since we allow agents to execute arbitrary python, we treat every container as hostile. we've definitely seen logs of agents trying to crawl /proc or hit the k8

since we allow agents to execute arbitrary python, we treat every container as hostile. we've definitely seen logs of agents trying to crawl /proc or hit the k8s metadata api. gvisor intercepts those syscalls so they never actually reach the host kernel.

rootnod3 7mo ago
And you see no problem in that at all? Just “throw a box around it and let the potentially malicious code run”? Wait until they find a hole. Then good luck.
- alexzenla 7mo ago
  This is why you can't build these microVM systems to just do isolation, it has to provide more value than that. Observability, policy, etc.
alexzenla 7mo ago
The reason why virtualization approaches with true Linux kernels is still important is what you do allow via syscalls ultimately does result in a syscall on the host system, even if through layers of indirection. Ultimately, if you fork() in gVisor, that calls fork() on the host (btw fork() execve() is expensive on gVisor still). The middle ground we've built is that a real Linux kernel interfaces with your application in the VM (we call it a zone), but that kernel then can make specialized and specific interface calls to the host system. For example with NVIDIA on gVisor, the ioctl()'s are passed through directly, with NVIDIA driver vulnerabilities that can cause memory corruption, it leads directly into corruption in the host kernel. With our platform at Edera (https://edera.dev https://edera.dev), the NVIDIA driver runs in the VM itself, so a memory corruption bug doesn't percolate to other systems.
- syzcowboy99 7mo ago
  > Ultimately, if you fork() in gVisor, that calls fork() on the host This isn't true. You can look at the code right here[1], there is no code path in gVisor that calls fork() on the host. In fact, the only syscalls gVisor is allowed to make to the host are listed right here in their seccomp filters[2]. [1] https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/sys_thread.go https://github.com/google/gvisor/blob/master/pkg/sentry/sysc... [2] https://github.com/google/gvisor/tree/master/runsc/boot/filter/config https://github.com/google/gvisor/tree/master/runsc/boot/filt...
  - alexzenla 7mo ago
    I was more specifically referring to the fact that to implement threads in gVisor, it calls to the go runtime, which does make calls to clone() (not fork()), but I see the pushback :) I think it's a small distinction. fork() itself isn't all that useful anyways. However, consider reading a file in gVisor. This passes through the IO layers, which ultimately will end up a read in the kernel, through one of the many interfaces to do so.

rootnod3 7mo ago

And you see no problem in that at all? Just “throw a box around it and let the potentially malicious code run”? Wait until they find a hole. Then good luck.

alexzenla 7mo ago
This is why you can't build these microVM systems to just do isolation, it has to provide more value than that. Observability, policy, etc.

alexzenla 7mo ago

The reason why virtualization approaches with true Linux kernels is still important is what you do allow via syscalls ultimately does result in a syscall on the host system, even if through layers of indirection. Ultimately, if you fork() in gVisor, that calls fork() on the host (btw fork() execve() is expensive on gVisor still). The middle ground we've built is that a real Linux kernel interfaces with your application in the VM (we call it a zone), but that kernel then can make specialized and specific interface calls to the host system. For example with NVIDIA on gVisor, the ioctl()'s are passed through directly, with NVIDIA driver vulnerabilities that can cause memory corruption, it leads directly into corruption in the host kernel. With our platform at Edera (https://edera.dev https://edera.dev), the NVIDIA driver runs in the VM itself, so a memory corruption bug doesn't percolate to other systems.

syzcowboy99 7mo ago
> Ultimately, if you fork() in gVisor, that calls fork() on the host This isn't true. You can look at the code right here[1], there is no code path in gVisor that calls fork() on the host. In fact, the only syscalls gVisor is allowed to make to the host are listed right here in their seccomp filters[2]. [1] https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/sys_thread.go https://github.com/google/gvisor/blob/master/pkg/sentry/sysc... [2] https://github.com/google/gvisor/tree/master/runsc/boot/filter/config https://github.com/google/gvisor/tree/master/runsc/boot/filt...
- alexzenla 7mo ago
  I was more specifically referring to the fact that to implement threads in gVisor, it calls to the go runtime, which does make calls to clone() (not fork()), but I see the pushback :) I think it's a small distinction. fork() itself isn't all that useful anyways. However, consider reading a file in gVisor. This passes through the IO layers, which ultimately will end up a read in the kernel, through one of the many interfaces to do so.