Anbox doesn't claim host OS needs to be Android. It claims opposite.
Conversation
Replying to
That's not what I said. I said that you need the host to have an Android kernel. They use modules to make it into one if it isn't built with Android support included:
github.com/anbox/anbox-mo
The Android container uses the host kernel directly including the Binder module.
1
Replying to
It's how it works on ChromeOS too, but on ChromeOS, I'm quite sure they preserve the usual sandboxing / security model / kernel attack surface reduction that's done primarily via SELinux. Anbox disables Android's SELinux usage, which is how a lot of the security model is done.
1
Replying to
What I'm interested in needs no internal security model because it's single privilege domain (one app). Only isolation from host.
1
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.
The original ChromeOS approach didn't give Android apps direct kernel access. It compiled them to NaCl apps (would be WebAssembly instead now doesn't make much difference) which have low-level containment for native code and are also run inside the tight browser renderer sandbox.
1
1
Show replies
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
Show replies