Conversation

Replying to
The internal security model protects the kernel from apps, and hides a lot of information leaked from the kernel to apps. By disabling SELinux, it's substantially breaking down the separation between the kernel and the app, making it less isolated than it would be even normally.
2
Replying to
You can't avoid mounting the stuff that the system and apps depend on to run. You are running a whole Android userspace instance including init, vold and all the privileged base system components inside the container. Security model protects the kernel and base system from apps.
2
Replying to
It's designed around doing that though, which is why they are using namespaces the way that they are. If you just want an Android runtime and apps, you don't need to approach it this way. Can be done like Fuchsia or the original ChromeOS approach which used NaCl not containers.
2
Replying to
The original ARC approach worked fine elsewhere. There was an ARChon fork designed to be used outside ChromeOS. Their new container approach is fundamentally less secure but a lot easier to implement. It at least preserves the security model and sandboxing model though.
1
Replying to and
Anbox is essentially the same thing as the new ChromeOS implementation. I don't like the new ChromeOS implementation since it gave up on securing it more than simply running Android natively. It was nice that it ran apps in a solid sandbox instead of just Android in a container.
1
1
Replying to and
In ChromeOS, they do have the container properly separated, but it trusts user namespaces. The security model inside Android is preserved though, so the kernel is protected to the same extent as native Android, and internal security model is still fully intact. It's not as bad.
1