4 ms·

I wonder how this is similar or different to FreeBSD jail; which has existed for the past 13+ years. https://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&s

• cyphar 9y ago
  Very different. It's also very different to Solaris Zones. The design of Linux containers is namespace-based while Jails and Zones are (basically) ID-based. In addition gVisor is basically a ptrace wrapper around your process that applies restrictions and other things on top of containers. I don't really understand what the benefit is over seccomp-bpf (which is slowly becoming as powerful as ptrace but without the overhead and without the security flaw of your sandbox rules being entirely in userspace without any protections like seccomp). They call it a kernel, likely because it is based on the idea of USL (User-Space Linux), but there's a reason that USL never took of as a virtualisation tool -- its entire security was predicated on ptrace to trick processes spawned in the "guest os" into not being able to see the host. In this configuration it looks like gVisor is using both namespaces and ptrace -- but then you have to worry about the massive overhead of ptrace (it affects every syscall and signal event involving the process, and requires four context switches and signal delivery to the tracing process in addition to the normal syscall costs). gAdvisor appears to be working on a KVM shim, but I'm not quite sure how you can use KVM and still differentiate yourself from Kata Containers (the project that came from Clear Containers and HyperHQ). Seems like duplicated effort to me. EDIT: I just re-read the article and it looks like they don't actually use containers at all. Unless I'm mistaken this means that they are not taking advantage of any of the sophisticated security primitives in the kernel that ordinary containers use, and thus have the same (bad) security model as UML.
  • antoncohen 9y ago
    I recommend reading the GitHub README[1]. > I don't really understand what the benefit is over seccomp-bpf With seccomp-bpf you are filtering what syscalls can be made, but those syscall still happen in the host kernel. If that kernel syscall has a vulnerability it could allow exploitation of the host and other containers in a multi-tenancy environment. The gVisor kernel actually implements the syscalls, it doesn't just pass them on. > Advisor appears to be working on a KVM shim, but I'm not quite sure how you can use KVM and still differentiate yourself from Kata Containers Kata Containers virtualize hardware and run a regular Linux kernel on the virtual hardware. gVisor doesn't virtualize hardware, it is a kernel running in userspace, implementing syscalls. > I just re-read the article and it looks like they don't actually use containers at all. Unless I'm mistaken this means that they are not taking advantage of any of the sophisticated security primitives in the kernel that ordinary containers use, and thus have the same (bad) security model as UML. The gVisor kernel (Sentry) runs in an empty user namespace with seccomp filters applied. [1] https://github.com/google/gvisor https://github.com/google/gvisor
    • cyphar 9y ago
      > With seccomp-bpf you are filtering what syscalls can be made, but those syscall still happen in the host kernel. I'm not sure what the distinction you're making is. By the same token, because PTRACE_SYSCALL/PTRACE_SYSEMU only signals the calling process after the syscall boundary has been crossed, then ptrace also doesn't help with the problem you are describing (though I also don't really agree that it's a problem in the first place -- user-kernel context switches are not security vulnerabilities). In fact, the seccomp restrictions are applied immediately after PTRACE_SYSCALL/PTRACE_SYSEMU -- there is only a few lines of code separating the two cases in the syscall entry path[1]. And in the case of PTRACE_SYSEMU, seccomp rules are still executed even though the syscall is never going to be executed. > gVisor doesn't virtualize hardware, it is a kernel running in userspace, implementing syscalls. I understand that, but that's the ptrace helper (which I spent the rest of my comment talking about). In the README (which I did read before commenting) they mention an experimental KVM driver, which is what my VM comments were referring to. Is there an explanation somewhere about how gVisor uses KVM to virtualize syscalls? I'm not sure I understand how you could use KVM to do that. That's why I mentioned Kata, because it's the only point of reference I have for using KVM to "emulate syscalls" (though of course it emulates more than that). > The gVisor kernel (Sentry) runs in an empty user namespace with seccomp filters applied. Good to know, but I didn't see that mentioned anywhere? If you're affiliated with the project it'd be great if you could add it somewhere in the README or the blog post. [1]: https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/entry/common.c#L81 https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/ent...
      • ithkuil 9y ago
        I started by reading here https://github.com/google/gvisor/blob/master/pkg/sentry/platform/kvm/kvm.go https://github.com/google/gvisor/blob/master/pkg/sentry/plat... Basically the Sentry binary works as both the VMM and the guest kernel. It uses the KVM API to setup page an address space and installs fault handlers through which it regains control when the guest payload faults (on memory access or soft interrupts/sysenter). What I couldn't find on a quick skin is how much of that logic works on which "side" of the wall, i.e. how much logic can the Sentry evaluate without crossing the VM boundary. I can imagine this can depend quite a lot on Go runtime internals. How do you setup the environment inside the "guest" so that it can run the Go code?
• geofft 9y ago
  jail (and its Linux equivalent, namespaces) is a kernel feature. This is a userpace application that emulates all system calla. "Container" is only used here in the sense of API / functionality, not implementation. Basically it is like running an application inside qemu, but lighter-weight.