I consider running Android applications in Anbox instead of running them in a virtual machine (Android-x86 in GNOME Boxes using QEMU with KVM). Does it increase the chances that malicious code in an Android app will get unauthorized access to the host system user's files?
According to Anbox.io website:
Anbox puts Android apps into a tightly sealed box without direct access to hardware or your data.
They list LXC containers among the technologies they use.
The main difference between virtualization and containerization is that, while a virtual machine is running a full independent Operating System on the guest, a container is run by the same Operating System kernel of the host but with a different userland (TL;DR: Programs and folders around it. On most desktop Linux distributions it's GNU).
This means that if you run a Debian container on a machine with Fedora, the Linux kernel on both is the same. Not the same version nor the same kernel executed in parallel, there is just one kernel running that pretends there are two OSs with different network and other hardware interfaces but, as Linux is monolithic, the drivers controlling them are the same, as they are all packed inside the kernel.
As Android is another Linux distribution (just not GNU) it can be run in a container on most desktop distributions. However, as there is no kernel isolation, if there happens to be a vulnerability in it (or in some paleolithic storage device driver that nobody cares about anymore) a malicious Android app could exploit it and gain control over the two machines (container and host) for the price of one.
On the other hand, virtual machine hypervisors (QEMU, Xen, KVM) are also made by human programmers and sometimes their virtual hardware controllers have bugs too. However, there's a lot fewer virtual than real devices to write drivers for (usually only one of each kind on each hypervisor, which makes the attack surface much smaller) and, on modern hardware, virtual machine isolation is backed by the chipset and CPU, which makes it really hard for virtualized OSs to even know what physical machine they are running on.
Containers make sense when performance is more important than security but a security layer is still wanted: for example, if all the installed apps are open source and one does not plan on getting into "risky behaviours" then it would be quite reasonable to use containers instead of VMs.
Last but not least, independently of whether containers or VMs are being used, the CPU on the physical machine should not be vulnerable to speculative execution exploits (or at least have it disabled on the BIOS settings, although it makes the computer much slower) and preferably use Error-Correcting Code memory (the one used in servers and workstations) in order to prevent Row hammer attacks.
