3 ms·

If you run a program on a virtual machine, then it is not "running on your computer". I strongly disagree. This is an equivocation of the words "running on you

by javert 15y ago

If you run a program on a virtual machine, then it is not "running on your computer". I strongly disagree. This is an equivocation of the words "running on your computer," though I understand the technical reason why you might say what you did. Honestly, this article comes across as poor excuse-making by Microsoft for not having decent security. Especially if you are unwilling to simply take as given the perfection of the virtual machine... which history says is not a wise thing to take as a given. From what I can tell, process virtual machines can provide a very good sandbox that allows you to safely run arbitrary code, modulo whatever permissions you explicitly give it. Yes, writing a fully correct virtual machine is surely very difficult, but software can be secured eventually by trial and error, especially if the codebase is kept small, which you can (in principle) do with a process virtual machine. If you have citations to show me why I'm wrong on this aspect, I'd appreciate it, as I have a genuine intellectual interest in VM security.

jerf 15y ago
And I disagree with your disagreement. The different phrasing captures an important security aspect of running software, it is not merely a semantic game. You're trying to present VMs as an easy answer to security, and I'm trying to show you why that's not a valid way of approaching the question. Trying to game the definitions won't undo my points here. "From what I can tell, process virtual machines can provide a very good sandbox that allows you to safely run arbitrary code, modulo whatever permissions you explicitly give it." Take your choice of virtual machine, and poke it into the search box on http://osvdb.org/ http://osvdb.org/ . Don't forget the things you might not consider VMs, like the Javascript engines in the browsers. I know that's less "citation" than "metacitation", but in the spirit of teaching one to fish I think it's more useful. Or just google it, plus the word "vulnerability". As an acceptable technique for quickly and easily securing low-security-requirement applications, sure. As an easy answer for everything, no, their history does not suggest that's the answer. I'm not aware of any VM that hasn't had a history of at least some bad vulnerabilities, and what confidence can you have that there aren't others lying in wait for any given VM? (Interestingly, OSVDB doesn't have anything for Google nativeclient, but Google search does.)
- javert 15y ago
  Saying "there are lots of VMs with security problems, therefore VMs cannot be secure" is faulty logic. Most (perhaps all) existing VMs are quite complicated and are not designed specifically to be secure, but that does not have to be the case. I bet I could write a secure VM in C that interprets some simple toy "virtual machine code" with around, say, 2^5 instructions. What I have in mind here is something like TinyVM [1]. [1] https://github.com/GenTiradentes/tinyvm https://github.com/GenTiradentes/tinyvm
  - arethuza 15y ago
    Youd should: - Implement your VM - Release the source code for inspection - Provide a way for anyone to upload code (e.g. via the web) into an instance of the VM on a server you control - Give an increasing bounty for each security bug found - Publically state that you are encouraging people to try cracking it That would be fun :-)

by javert 15y ago

jerf 15y ago

And I disagree with your disagreement. The different phrasing captures an important security aspect of running software, it is not merely a semantic game. You're trying to present VMs as an easy answer to security, and I'm trying to show you why that's not a valid way of approaching the question. Trying to game the definitions won't undo my points here. "From what I can tell, process virtual machines can provide a very good sandbox that allows you to safely run arbitrary code, modulo whatever permissions you explicitly give it." Take your choice of virtual machine, and poke it into the search box on http://osvdb.org/ http://osvdb.org/ . Don't forget the things you might not consider VMs, like the Javascript engines in the browsers. I know that's less "citation" than "metacitation", but in the spirit of teaching one to fish I think it's more useful. Or just google it, plus the word "vulnerability". As an acceptable technique for quickly and easily securing low-security-requirement applications, sure. As an easy answer for everything, no, their history does not suggest that's the answer. I'm not aware of any VM that hasn't had a history of at least some bad vulnerabilities, and what confidence can you have that there aren't others lying in wait for any given VM? (Interestingly, OSVDB doesn't have anything for Google nativeclient, but Google search does.)

javert 15y ago
Saying "there are lots of VMs with security problems, therefore VMs cannot be secure" is faulty logic. Most (perhaps all) existing VMs are quite complicated and are not designed specifically to be secure, but that does not have to be the case. I bet I could write a secure VM in C that interprets some simple toy "virtual machine code" with around, say, 2^5 instructions. What I have in mind here is something like TinyVM [1]. [1] https://github.com/GenTiradentes/tinyvm https://github.com/GenTiradentes/tinyvm
- arethuza 15y ago
  Youd should: - Implement your VM - Release the source code for inspection - Provide a way for anyone to upload code (e.g. via the web) into an instance of the VM on a server you control - Give an increasing bounty for each security bug found - Publically state that you are encouraging people to try cracking it That would be fun :-)