5 ms·

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 chr

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.
  - ww520 15y ago
    And what are the evidence of VM based isolation have more security?
    - justincormack 15y ago
      It is a layered approach, first you wold have to find an exploit in the "VM" (which is a sandbox really) thn exploit the underlying OS. The VM has a much smaller attack surface as you have less you can do, so it is easier to audit. NaCl, which is used here has had minor flaws http://arstechnica.com/open-source/news/2009/07/google-nacl-security-contest-uncovered-vulnerabilities.ars http://arstechnica.com/open-source/news/2009/07/google-nacl-... but nothing like straight kernel. Sure there are other approaches eg see http://sandboxing.org/ http://sandboxing.org/ eg to use selinux to constrain processes, but none are easy. There is some more recent work on more directly limiting syscalls to processes which is another approach, so the OS provides an isolation service.
    - 15y ago

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.
- ww520 15y ago
  And what are the evidence of VM based isolation have more security?
  - justincormack 15y ago
    It is a layered approach, first you wold have to find an exploit in the "VM" (which is a sandbox really) thn exploit the underlying OS. The VM has a much smaller attack surface as you have less you can do, so it is easier to audit. NaCl, which is used here has had minor flaws http://arstechnica.com/open-source/news/2009/07/google-nacl-security-contest-uncovered-vulnerabilities.ars http://arstechnica.com/open-source/news/2009/07/google-nacl-... but nothing like straight kernel. Sure there are other approaches eg see http://sandboxing.org/ http://sandboxing.org/ eg to use selinux to constrain processes, but none are easy. There is some more recent work on more directly limiting syscalls to processes which is another approach, so the OS provides an isolation service.
  - 15y ago