Hi, * Colin Watson <cjwat...@debian.org> [2023-07-14 11:50]:
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.
Hm, I didn't think of it that way. Thank you both for your insights! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
signature.asc
Description: PGP signature
