Hacker News Reader

Comment by qixxiq | Hacker News Reader

The Law #1 seems to have been proved wrong. I'm against closed systems but what the iPad/iPhone have done in terms of security is fantastic.

It would be great if other systems worked as smoothly. I'm particularly disturbed by Android's permission system (only tested on stock Nexus S). You are shown a list of permissions but I don't see why I have to allow Twitter access to my contact information and gps location.

I understand it improves the experience but personally I would rather have those turned off and the twitter application should be able to deal with that choice (rather than me having to deal with Twitter having access to my location and full contact list)

View on HN

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?

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.

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.

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.

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.

But that's an OS design flaw, not an "immutable law". It doesn't apply to, say, EROS.

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.

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.

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/ . 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.)

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

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 :-)

What about nacl? http://code.google.com/p/nativeclient/

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.)

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.

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.

Thanks for all the excellent info :-)

There are two points I'd put in reply:

1) They only allow you to download apps they've vetted, not just any old application. Yes, this review process increases security.

2) It's somewhat better in that respect, but not perfect. Imagine a malicious version of jailbreak.me, for example. Yes, they use security holes to perform that operation.

There are some apps (all requiring root) that allow selective permissions for android apps. I like knowing what the app wants to be able to do and if something strange sticks out, I'll look it up or block it.

>You are shown a list of permissions but I don't see why I have to allow Twitter access to my contact information and gps location.

On your iphone, the twitter app has the same permissions but nobody tells you about it. Only upside is, that you can disable the gps access.

Law #1 looks pretty good.

Apple here is the trusted friend. A jailbreak is like the sandwich on the street. The friends checking isn't infallible, but it's good enough that you can normally trust them.

Reply on news.ycombinator.com