It doesn't provide meaningful sandboxing and doesn't approach it the way that you want. Their comparison to the Android integration in ChromeOS is also wrong / misleading. You're better off using the Android emulator for a KVM / QEMU based VM without everything hacked together.
Conversation
Using the standard VM approach isn't substantially more heavyweight. It performs well and is much more robust and compatible. ChromeOS isn't currently using virtualization for performance reasons but they really should be doing it that way. As is, it turns ChromeOS into Android.
2
There's not really that much difference between using Android with Chrome in the app sandbox or using ChromeOS with Android inside a container. The kernel is the same, verified boot and update system is comparable, and security between apps and Chrome is essentially the same too.
2
Replying to
Yes, but I don't want any of that. Not their kernel, not verified boot, etc. Stock Linux kernel (or in the future, something better) and ability to run legacy apps safely.
1
Replying to
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.
1
1
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
They are using a native Binder implementation, etc. in the host kernel, so you fundamentally only have a single instance of Android as an OS. You cannot approach it like Anbox or ChromeOS to get what you want which is having entirely separate instances of Android instead of one.
1
1
Anbox is also disabling most of the Android security model including drastically weakening the app sandbox since that's heavily implemented with SELinux policy which they are disabling. So you don't even have the usual isolation between apps and between profiles inside of it.
1
2
Essentially what it does is have a partially contained Android OS via namespaces with an Android kernel on the 'host', with most of the Android security model disabled. Usually, profiles provide very good isolation between groups of apps, and the app sandbox is pretty strong.
That's not the case if you turn off the security model like that though. Really, there is less isolation between an app inside it and an app on the host OS outside of it than there would usually be between apps on Android and especially between the fully isolated user profiles.
1
1
It gives apps far more access to the kernel than they would have on a native system. SELinux is used to restrict most access to /proc, /sys and to do a lot of kernel attack surface reduction including with features like ioctl filtering, etc. Kills most of the sandboxing off too.