3 ms·

(P)NaCl already solves this problem, without such hacks as transparently spinning up a virtual machine. I don't trust Virtualbox to be especially resilient to

(P)NaCl already solves this problem, without such hacks as transparently spinning up a virtual machine. I don't trust Virtualbox to be especially resilient to attacks from malicious VMs. Chrome's sandbox is well-audited and (overall) is sound. A virtual machine host has a much larger attack surface, and generally doesn't assume malicious guests.

grun 13y ago
Native Client 1) Is Chrome only. 2) Can't spawn processes or subprocesses. 3) Can't open raw UDP or TCP sockets. 4) Requires apps be ported.
- dekhn 13y ago
  While I like the idea of running a VM in a browser (not sure if I'm convinced it makes sense, I still like the idea): Argument #1 only makes sense if you support a lot of platforms. Right now you only support Mac OS X (according to another comment). The number of people who use Chrome globally is larger than the number of people who use Mac OS X. Ergo, if you used Native Client and chrome, you'd be more ubiquitous. Regarding sockets: chrome supports UDP and TCP: http://developer.chrome.com/apps/socket.html http://developer.chrome.com/apps/socket.html If there's one platform to build on that is going to cover a large number of people and give close to native performance, it's Chrome+PNaCl. I wouldn't tell everybody to drop what they're doing and adopt that target (it's not ready yet). VMs in the browser are pretty nascent, too.
- iuguy 13y ago
  Why do you think that is? Is it because Google have a large team of engineers who have developed a proper security programme for the project and realised that doing 2 and 3 are bad and that as a result of that and other problems with diong this that 4 is necessary? There are reasons for these limitations.
regularfry 13y ago
VM hosts have assumed malicious guests ever since people started renting out VMs. It's a VPS host's nightmare to have a VM root exploit be escalatable to expose all the other VMs on that VM's host.
rdl 13y ago
I trust virtualization as a security boundary, particularly on modern CPUs with stuff like VT-d/VT-x, more than process separation on Unix/Windows. I still trust hardware separation a lot more, particularly because it is so much easier to audit and put multilayer controls on, particularly vs. administrative users. Virtualbox in specific might be a vulnerability compared to other virtualization systems, though.
ksk 13y ago
Um.. transparently spinning up a VM is not a hack. Its the actual design ! >Chrome's sandbox is well-audited and (overall) is sound. So why does it fail during the annual Pwn2Own competition? You and I have different definitions of 'sound'. Also coming back to NaCL.. NaCl's code verifier has never undergone large scale deployment/testing/real world use from millions of users/apps.

grun 13y ago

Native Client 1) Is Chrome only. 2) Can't spawn processes or subprocesses. 3) Can't open raw UDP or TCP sockets. 4) Requires apps be ported.

dekhn 13y ago
While I like the idea of running a VM in a browser (not sure if I'm convinced it makes sense, I still like the idea): Argument #1 only makes sense if you support a lot of platforms. Right now you only support Mac OS X (according to another comment). The number of people who use Chrome globally is larger than the number of people who use Mac OS X. Ergo, if you used Native Client and chrome, you'd be more ubiquitous. Regarding sockets: chrome supports UDP and TCP: http://developer.chrome.com/apps/socket.html http://developer.chrome.com/apps/socket.html If there's one platform to build on that is going to cover a large number of people and give close to native performance, it's Chrome+PNaCl. I wouldn't tell everybody to drop what they're doing and adopt that target (it's not ready yet). VMs in the browser are pretty nascent, too.
iuguy 13y ago
Why do you think that is? Is it because Google have a large team of engineers who have developed a proper security programme for the project and realised that doing 2 and 3 are bad and that as a result of that and other problems with diong this that 4 is necessary? There are reasons for these limitations.

regularfry 13y ago

VM hosts have assumed malicious guests ever since people started renting out VMs. It's a VPS host's nightmare to have a VM root exploit be escalatable to expose all the other VMs on that VM's host.

rdl 13y ago

I trust virtualization as a security boundary, particularly on modern CPUs with stuff like VT-d/VT-x, more than process separation on Unix/Windows. I still trust hardware separation a lot more, particularly because it is so much easier to audit and put multilayer controls on, particularly vs. administrative users. Virtualbox in specific might be a vulnerability compared to other virtualization systems, though.

ksk 13y ago

Um.. transparently spinning up a VM is not a hack. Its the actual design ! >Chrome's sandbox is well-audited and (overall) is sound. So why does it fail during the annual Pwn2Own competition? You and I have different definitions of 'sound'. Also coming back to NaCL.. NaCl's code verifier has never undergone large scale deployment/testing/real world use from millions of users/apps.