On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote: > On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > > qemu is basically an interpreter for foreign machine code. If your > > threat model allows access to qemu-user-static for an attacker, they > > can run pretty much any binary is if it were native, and the whole > > SystemCallArchitectures hardening becomes meaningless. > > My understanding of the threat is that compatibility syscalls (eg, x32 > on amd64) are less well-tested than the local architecture syscalls, and > so allowing apps to call them increases the risk - a compromised app > that can make compatibility syscalls stands a higher probability of > being able to elevate privileges, either in userland or to the kernel > itself. Allowing qemu to translate syscalls from other architectures to > the local syscall ABI doesn't increase that risk, so isn't a concern. > The goal isn't to prevent code form other architectures from running, > it's to reduce the attack surface by preventing calls to the > compatbility syscalls.
Not just that, but also using compatibility syscalls allows circumventing other systemd hardening that filters syscalls (RestrictAddressFamilies=, MemoryDenyWriteExecute=, SystemCallFilter=). Allowing qemu also doesn't make much difference either way to that though - if your process can't make a syscall directly, it can't make it via qemu either. -- Colin Watson (he/him) [cjwat...@debian.org]
