On Fri, Nov 06, 2026 at 01:27:34PM -0600, Eric Blake wrote: > Not all NBD protocol violations are equal. If a malicious server or > client can trigger a QEMU assertion failure on a plaintext connection, > but can be trivially mitigated by enabling TLS to weed out untrusted > partners that would violate the protocol in the first place, then the > bug does not need to be embargoed. Spell this out in our policy. > > Signed-off-by: Eric Blake <[email protected]> > --- > docs/system/security.rst | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/docs/system/security.rst b/docs/system/security.rst > index e211fdd2344..29bb3e9b2a1 100644 > --- a/docs/system/security.rst > +++ b/docs/system/security.rst > @@ -143,6 +143,17 @@ an issue as a normal bug. > which case plain manipulation of the stream is not considered as > an attack vector. > > +* **network protocols**. In scenarios involving a network connection, > + such as NBD block devices, some bugs might be triggered when a > + malicious server or client on the other side of the connection > + intentionally violates the expected protocol. However, to be > + considered as a security attack vector, the bug must be reproduced > + prior to QEMU completing a TLS handshake with the remote partner. If > + the bug relies on a plaintext connection, or can only be triggered > + after first successfully negotiating TLS to filter out untrusted > + connections, then it will be treated as a hardening bug but not a > + security flaw.
I don't think we can be so broad in ruling out these flaws as security bugs, merely by performing an authorization check of the client via a TLS certificate. This works in the case of live migration, because both sides of the network connection are inherently operating at the same privilege level, as they both have full access to the QEMU VM workload. In the case of NBD, an authorized client can still be considered to operate at a lesser privilege level than QEMU. We can have exported 1 disk via NBD, but if the authorized client expoits a bug in QEMU and thus accesses unrelated data that is still a privilege violation. In the NBD case, an example where we could rule out a security issue, is if an NBD protocol exploit leaked a disk sector for the dis that was already exported over NBD, as it would not be giving info that the NBD client was not already authorized to have. Many (possibly most) NBD bugs, however, I think will end up being security issues. If they have a "low" severity, however, we can rule our security handling via our catch all rule. > * **uninitialized stack variables**. If the bug scenario relies on > undefined behaviour from stack variables that lack explicit > initialization, it will not usually be considered a security flaw. > @@ -320,3 +331,16 @@ encryption and authorization control policy on client > connections. > In summary, the monitor console is considered a privileged control interface > to > QEMU and as such should only be made accessible to a trusted management > application or user. > + > +Block device network protocols (NBD, NFS, etc.) > +''''''''''''''''''''''''''''''''''''''''''''''' > + > +When using QEMU to access remote storage over a network (such as QEMU > +acting as an NBD or NFS client) or to provide remote storage access > +(such as QEMU acting as an NBD server), it is important to realize > +that an unencrypted connection can allow an external process a > +potential attack vector over the network port. The general > +recommendation is that if the protocol allows the use of TLS, then the > +management application must configure the use of TLS, in order to > +limit the impact of unauthorized or man-in-the-middle attacks to the > +smaller region of time before the TLS handshake takes place. Performing TLS only protects against a MITM attack by default. To protect further scenarios we must document that the protocol must have x509 client certificates issued to authorized clients and the tls-creds-x509 object set 'verify-peer=on' to check them, potentially also 'tls-authz' to filter which certificates are allowed if the CA issues certs more broadly. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
