[RFC] qemu-server: add opt-in support for QEMU seccomp sandbox

[Bogdan Ionescu <bogdan@ionescu.at>]

Hi all,

I'd like to gauge interest in exposing QEMU's built-in seccomp sandbox as a first-class qemu-server option, before preparing a patch.

== Motivation ==

QEMU provides the -sandbox on option, which installs a seccomp mode 2 syscall filter for the QEMU process.

The PVE QEMU package is already built with seccomp support (--enable-seccomp), so this currently works when added manually to a VM configuration:

args: -sandbox on

There is, however, no first-class qemu-server option for enabling it.

Since the QEMU process represents a significant part of the attack surface between an untrusted guest and the host, enabling QEMU's own syscall filtering seems like a relatively small additional defense-in-depth measure.

This is complementary to the AppArmor-for-KVM discussion from last year, but considerably smaller in scope since the filtering and policy are maintained upstream by QEMU and don't require generating per-VM filesystem profiles.

There is also an existing feature request for this, #6413.

== Proposal ==

Initially expose the basic QEMU sandbox as an opt-in per-VM setting, e.g.:

sandbox: 1

or:

qm set <vmid> --sandbox 1

which would cause qemu-server to add:

-sandbox on

to the QEMU command line.

I would intentionally keep the first implementation limited to plain
-sandbox on.

In particular, I would not initially enable the additional QEMU sandbox
restrictions:

elevateprivileges=deny
spawn=deny
resourcecontrol=deny

Those could potentially interfere with less common QEMU configurations or
features and could be evaluated separately once the basic sandbox has had
wider testing.

The initial semantics would therefore be:

- disabled by default, so existing VMs are unchanged
- per-VM opt-in
- API/CLI/config support in qemu-server
- -sandbox on added only when enabled
- no pve-qemu changes required
- cfg2cmd tests for both enabled and disabled cases
- documentation describing it as an additional defense-in-depth measure

I've also tested the equivalent args: -sandbox on configuration without

observing issues so far, for the past year, on hundreds of VMs.

== Possible future direction ==

If it proves sufficiently compatible, we could later consider:

- enabling the sandbox by default for newly created VMs
- exposing some or all of the additional QEMU sandbox restrictions
- enabling stronger defaults where qemu-server knows they are safe

I think keeping those separate from the initial implementation would make
it much easier to evaluate compatibility.

== Open questions ==

- Would a first-class opt-in QEMU seccomp sandbox option be acceptable in
principle?
- Would you prefer a simple boolean sandbox option initially, or a
property string so that the additional QEMU sandbox options can be
exposed later without changing the configuration format?
- Is plain -sandbox on conservative enough for an initial implementation,
or would you prefer some of the additional restrictions to be enabled
from the beginning?
- If compatibility testing looks good, would making this the default for
new VMs eventually be desirable?

If the direction sounds reasonable, I can prepare the qemu-server patch
and tests.

Thanks,
Bogdan