5 ms·

Actually as long as you set up your permission correctly, you can run any untrusted user-mode C code (non-privileged code). Just deny access to most of the sys

• eklitzke 15y ago
  I think in practice there have been a few historical problems with this approach. A major one is that while in theory it's possible to secure a process to a chroot jail (either the Linux or the BSD variety) in practice it's hard to defend against arbitrary, possibly malicious programs in that jail. Kernel exploits that rely on local access are uncommon but not incredibly rare. You could easily have a hosting service like this that ran fine for a few months, or even a few years, and then a 0-day kernel exploit comes out (that relies on having local access to the machine) and then you're SOL. Another issue is that in practice some system calls are very expensive. With a little knowledge you can DOS a machine hosting your process if you can run arbitrary system calls -- for instance, if you can create some sort of resource that is expensive for the kernel to track, and then create a lot of that resource. Sort of related to this, at least in Linux there are a very large number of syscalls and new ones are added relatively frequently, and not all syscalls have had the same amount of security auditing. Even if you're not worried about your own servers getting hacked, you need to convince your customers that other users aren't going to be able to intercept or modify their data or attack their VMs. In my mind, one of the main innovation of a lot of the VM stuff in recent years, and in particular the NaCL approach of limiting what system calls can be invoked, is that you are fundamentally reducing the interface by which malicious programs have to attack the hosting machine. If you can securely limit system calls to a small subset, you can more easily audit the paths those system calls make to ensure that they're secure and can't be used in a DOS scenario. In a virtualization environment like Xen or KVM, the amount of code that you have to audit is limited to the Xen/KVM code which is much smaller than the rest of the code base. Just my 2c., etc.
  • camuel 15y ago
    Thanks for that, I feel the same way for process isolation. In theory that should be a solution but in practice doesn't work for historic reasons. Just one comment. ZEROVM IS NOT NACL. It uses NaCl, moreover we explicitly refrained to touch validator in order to remain under its proven security blanket (Google established hefty monetary prizes for each found exploit). However, except of validator it is heavely refactored and rewritten. MAIN DIFFERENCE: NaCl has "syscall firewalling" feature that is called Pepper. ZeroVM forbids all host syscalls. In fact ZeroVM is a new virtual hadware architectures (a subset of x86 and subset of ARM and new ones in future) so there is no such concept for code running inside as "host syscalls".
    • justincormack 15y ago
      ARM support? Excellent, was going to look at adding this.
  • ww520 15y ago
    Thanks for the responses; however, most of the attacks to OS process can happen in ZeroVM. - Kernel exploits can happen, so can exploits in ZeroVM. - DOS attack on OS, so can DOS attack on ZeroVM. I don't see any quota system or resource management in ZeroVM to mitigate it. At least the OS have better tools to deal with it - priority, scheduler, resource manager, memory partition, etc. - Same thing for the customer worry. They could worry about other users attacking the ZeroVM or the host system. If you prefer security VM, there are a lot of mature VM's - JVM, .Net, Xen, or KVM. My point is there have been so much research, work, and experience have gone into the security in OS that I would trust an OS isolation than a new research system in term of security. It's easy to have a lock-down OS to restrict access to most subsystems.
    • prodigal_erik 15y ago
      Has OS isolation ever been implemented successfully? I think I've seen local root exploits reported for every OS I've heard of.