4 ms·

The Law #1 seems to have been proved wrong. I can't agree with you more. It seems to me that with interpretation (e.g. a Java virtual machine, for example), ex

by javert 15y ago

The Law #1 seems to have been proved wrong. I can't agree with you more. It seems to me that with interpretation (e.g. a Java virtual machine, for example), exactly what a program can do can be controlled precisely. Build a trusted interpreter, which should be possible (right?), and you're golden. One question: How does the security in iOS differ from that in Android? I'm only familiar with Android. I would imagine iOS must also have some kind of selective permission system?

jerf 15y ago
If you run a program on a virtual machine, then it is not "running on your computer". It is "running on a virtual machine, running on your computer", and the security implications are different. Law #1 still holds. 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. That's also which qixxiq is wrong in the GP post; it's only true if you assume that Apple's security is perfect. As a practical matter as a user it's a tolerable approximation, especially if you have no personal assets of value on your phone, but if you're really concerned about security it is not something you can assume.
- 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 :-)
- comex 15y ago
  Anything in a modern operating system other than the kernel can be considered to be running in a virtual machine; when people refer to running a program on their computer, they're not usually talking about kernel modules. Apple's security is not perfect, of course, but these are supposed to be immutable laws: we can't fix problems caused by them because they are fundamental to how computers work. It is possible in theory to build a completely secure kernel.
  - waitwhat 15y ago
    Anything in a modern operating system other than the kernel can be considered to be running in a virtual machine The level of isolation between processes running on the same machine doesn't really come close to that afforded to processes running inside different VMs.
    - wmf 15y ago
      But that's an OS design flaw, not an "immutable law". It doesn't apply to, say, EROS.
    - ars 15y ago
      Maybe it doesn't, but it could. So the first law doesn't seem correct. As the simplest example a multi uses unix operating system allows lots of people to run programs on the same computer and barring errors it works fine in separating them.
    - justincormack 15y ago
      Some resources are virtual, so yes it is a vm. Processes are one level, then there are bsd jails, linux containers, lots of vm types. All have different security issues, once processes seemed enough isolation. In the end the bugs matter most, and vm isolation has bugs too, they have just been harder to find and exploit. Security is not absolute, just a matter of degrees.
- andreyf 15y ago
  What about nacl? http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/
Xuzz 15y ago
iOS does not have a general purpose "permissions" system. It does, however, ask for permission (via a modal popup with an explanation) before performing some things that you might to deny, such as accessing your photo library or physical location. (However, most likely for legacy reasons, the Contacts isn't protected in the same way.) It's also enforced through the review process: in addition to checking for stability and compatibility, the iOS review process also checks for malware and some data theft. This is also helped by the fact that iOS apps cannot dynamically load code after the review process, so you can be pretty sure that Apple at least took a quick look at what you install. It's far from foolproof — I'm sure a dedicated attacker could sneak something through the review process and steal your contacts — but nothing has happened so far (at least as far as I know). (As a side note about the lack of a true "permissions" system: having the app request access when it makes sense (Twitter only asks for location when I tap the geotag button, for example) means that I know why the app is asking, rather than on Android where I've seen frantic messages in the description to explain why the app needs some theoretically-privacy-invading permission, even if it's only used for a minor feature, since just asking for that permission scared users away. Neither system is perfect, but a contextual system where you can allow or deny individual permissions (as on iOS) combined with full coverage of what permissions might be wanted to be controlled (as on Android) would work pretty well.)
- Sephr 15y ago
  Well actually on Android you can ask for no permissions up front, and then prompt for various single permissions later whenever appropriate, but this will lead to many confirmation dialogues that users probably won't like.
  - javert 15y ago
    What would be nice if the "you" in your sentence referred to "you, the end user." So the user chooses if they want permissions up front or in context.
- javert 15y ago
  Thanks for all the excellent info :-)

by javert 15y ago

jerf 15y ago

If you run a program on a virtual machine, then it is not "running on your computer". It is "running on a virtual machine, running on your computer", and the security implications are different. Law #1 still holds. 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. That's also which qixxiq is wrong in the GP post; it's only true if you assume that Apple's security is perfect. As a practical matter as a user it's a tolerable approximation, especially if you have no personal assets of value on your phone, but if you're really concerned about security it is not something you can assume.

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 :-)
comex 15y ago
Anything in a modern operating system other than the kernel can be considered to be running in a virtual machine; when people refer to running a program on their computer, they're not usually talking about kernel modules. Apple's security is not perfect, of course, but these are supposed to be immutable laws: we can't fix problems caused by them because they are fundamental to how computers work. It is possible in theory to build a completely secure kernel.
- waitwhat 15y ago
  Anything in a modern operating system other than the kernel can be considered to be running in a virtual machine The level of isolation between processes running on the same machine doesn't really come close to that afforded to processes running inside different VMs.
  - wmf 15y ago
    But that's an OS design flaw, not an "immutable law". It doesn't apply to, say, EROS.
  - ars 15y ago
    Maybe it doesn't, but it could. So the first law doesn't seem correct. As the simplest example a multi uses unix operating system allows lots of people to run programs on the same computer and barring errors it works fine in separating them.
  - justincormack 15y ago
    Some resources are virtual, so yes it is a vm. Processes are one level, then there are bsd jails, linux containers, lots of vm types. All have different security issues, once processes seemed enough isolation. In the end the bugs matter most, and vm isolation has bugs too, they have just been harder to find and exploit. Security is not absolute, just a matter of degrees.
andreyf 15y ago
What about nacl? http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/

Xuzz 15y ago

iOS does not have a general purpose "permissions" system. It does, however, ask for permission (via a modal popup with an explanation) before performing some things that you might to deny, such as accessing your photo library or physical location. (However, most likely for legacy reasons, the Contacts isn't protected in the same way.) It's also enforced through the review process: in addition to checking for stability and compatibility, the iOS review process also checks for malware and some data theft. This is also helped by the fact that iOS apps cannot dynamically load code after the review process, so you can be pretty sure that Apple at least took a quick look at what you install. It's far from foolproof — I'm sure a dedicated attacker could sneak something through the review process and steal your contacts — but nothing has happened so far (at least as far as I know). (As a side note about the lack of a true "permissions" system: having the app request access when it makes sense (Twitter only asks for location when I tap the geotag button, for example) means that I know why the app is asking, rather than on Android where I've seen frantic messages in the description to explain why the app needs some theoretically-privacy-invading permission, even if it's only used for a minor feature, since just asking for that permission scared users away. Neither system is perfect, but a contextual system where you can allow or deny individual permissions (as on iOS) combined with full coverage of what permissions might be wanted to be controlled (as on Android) would work pretty well.)

Sephr 15y ago
Well actually on Android you can ask for no permissions up front, and then prompt for various single permissions later whenever appropriate, but this will lead to many confirmation dialogues that users probably won't like.
- javert 15y ago
  What would be nice if the "you" in your sentence referred to "you, the end user." So the user chooses if they want permissions up front or in context.
javert 15y ago
Thanks for all the excellent info :-)