Anbox depends on having an Android kernel, i.e. having the Android modules like Binder. You are effectively running a whole Android OS since you've got an Android kernel and the whole userspace within namespaces. It's separated to some extent from the rest of the OS, but poorly.
Conversation
Unlike ChromeOS, they aren't actually implementing a proper isolation boundary around it with the namespaces and bridging. It has moved towards that, but it's not at that point. Even the ChromeOS implementation is really just properly separated / contained, not so much sandboxed.
1
If you want to avoid turning your 'host' OS into Android, you pretty much need either a virtual machine or another approach to intercepting all the system calls. github.com/google/gvisor uses either a ptrace (quite slow) or KVM (without running another Linux kernel) backend.
2
I don't think gVisor is close to the point where it could run Android inside it though. It would need a fair bit more work to reach that point. ChromeOS and Anbox are taking the short cut of just turning the host OS into Android, with Anbox also not doing meaningful isolation.
2
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
Namespaces are also really not complete and don't work properly for isolating pseudo-root. You are still going to have all the privileged components inside the Android container and are depending on the security model to protect them (and the base system) from the apps.
For example, if an app can get control within the container, it can load kernel netfilter policies, make all kinds of mounts and so on. All of that stuff is exposed to the Android container and you can't really work around that when using native kernel namespaces.
1