4 ms·

> Having one OS in a "vm" on a phone sounds horrible UX wise I believe most android people are doing this with users. Since Android is now up to the task of d

> Having one OS in a "vm" on a phone sounds horrible UX wise I believe most android people are doing this with users. Since Android is now up to the task of docker (kernel 3.10+), it would be very nice to see apps sandboxed with permissions exposed via networked APIs. Then it is impossible for an app (sans exploit) to access private data, and simple for the OS to route certain apps to certain data sets (ie, fake contacts for apps that shouldn't need your damn contact to begin with). CyanogenMod accomplished some of this through various methods, but they were detectable. If you build it this way, it should be entirely undetectable.

floren 9y ago
I had considered trying something like this with Hellaphone (Inferno as a replacement for Android's Java components). Because the Inferno VM is so lightweight (startup took less than a second once you were out of the bootloader), you could easily run one whole VM per application. Then just make some sort of multiplexer to swap between which VM has screen access at any one time. 9P would make a rather straightforward way to provide services for applications, too.
izacus 9y ago
How would your solution improve on current one, where apps are sandboxed by the permissions system and communicate via Binder which is also RPC based? You just added bunch of layers to architecture for no reason - none of serious Android exploits in years would be mitigated by your approach.
- chisleu 9y ago
  > You just added bunch of layers to architecture for no reason The sandbox doesn't do the isolation that docker can. It uses user isolation like I mentioned. The difference is that Binder is Java on top of the kernel, while docker is isolating from the kernel itself. Without access to the service, it is impossible, sans-kernel-exploit, to escape the permissions jail, or even tell if you are in a permissions jail if someone gives your app fake contact information by routing it to a different service. Docker isn't perfect. It had a serious CVE recently. I'm certainly not saying it is absolutely better. I'm just saying that I think they are fundamentally different and that process level isolation is superior to user level isolation.
  - izacus 9y ago
    Sure, but none of serious Android exploits had anything to do with escaping from the sandbox. They were mostly in driver and HW acceleration layers, which can't be sandboxed due to performance and DRM reasons.

floren 9y ago

I had considered trying something like this with Hellaphone (Inferno as a replacement for Android's Java components). Because the Inferno VM is so lightweight (startup took less than a second once you were out of the bootloader), you could easily run one whole VM per application. Then just make some sort of multiplexer to swap between which VM has screen access at any one time. 9P would make a rather straightforward way to provide services for applications, too.

izacus 9y ago

How would your solution improve on current one, where apps are sandboxed by the permissions system and communicate via Binder which is also RPC based? You just added bunch of layers to architecture for no reason - none of serious Android exploits in years would be mitigated by your approach.

chisleu 9y ago
> You just added bunch of layers to architecture for no reason The sandbox doesn't do the isolation that docker can. It uses user isolation like I mentioned. The difference is that Binder is Java on top of the kernel, while docker is isolating from the kernel itself. Without access to the service, it is impossible, sans-kernel-exploit, to escape the permissions jail, or even tell if you are in a permissions jail if someone gives your app fake contact information by routing it to a different service. Docker isn't perfect. It had a serious CVE recently. I'm certainly not saying it is absolutely better. I'm just saying that I think they are fundamentally different and that process level isolation is superior to user level isolation.
- izacus 9y ago
  Sure, but none of serious Android exploits had anything to do with escaping from the sandbox. They were mostly in driver and HW acceleration layers, which can't be sandboxed due to performance and DRM reasons.