Daniel P. Berrangé <[email protected]> writes: > The description of virtualization vs non-virtualization use > cases is a crude approximation of the security characteristics > of QEMU devices. > > Document how QEMU can be probed to obtain information on the > security status of type classes, and how policies can be set > to inform or control their usage. > > Signed-off-by: Daniel P. Berrangé <[email protected]> > --- > docs/system/security.rst | 43 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/docs/system/security.rst b/docs/system/security.rst > index f2092c8768..cda4bae6db 100644 > --- a/docs/system/security.rst > +++ b/docs/system/security.rst > @@ -49,6 +49,49 @@ Bugs affecting the non-virtualization use case are not > considered security > bugs at this time. Users with non-virtualization use cases must not rely on > QEMU to provide guest isolation or any security guarantees. > > +Security status reporting > +''''''''''''''''''''''''' > + > +QEMU is progressively working to annotate object types to explicitly state
Suggest "The QEMU project is working" > +whether they are considered to provide a security boundary or not. > + > +It is possible to control or identify the usage of types that do not offer > +an explicit security boundary using the ``insecure-types`` parameter to the > +``-compat`` argument, which accepts three values: > + > + * accept: usage of any type will be permitted. This is the current > + and historical default behaviour > + * warn: usage of types not explicitly declared secure will result > + in a warning message, but still be permitted. > + * reject: usage of types not explicitly declared secure will result > + in an error message, and will not be permitted. > + > +The compatibility policy will be honoured both at initial startup of > +QEMU and during any runtime alterations made with monitor commands. This is about QOM. It doesn't cover security boundaries outside QOM, e.g. in block backends. I think we better make this limitation quite clear here. > + > +The status of any type class can be queried at runtime using the > +``qom-list-types`` command, whose returned information will flag any > +types declared as secure. The ``query-machines`` command will also > +reflect this same information for machine types. > + > +Machine type, accelerator and device security status can be queried > +using ``-machine help``, ``-accel help`` and ``-device help`` command > +line options respectively. > + > +The setting of the ``.secure`` field at the time a type class is > +declared in the code will determine whether bugs are eligible to > +be considered as security bugs: > + > + * Explicitly declared ``.secure = true``: security bug process > + applies, eligible for CVE assignment > + * Explicitly declared ``.secure = false``: security bug process > + does not apply, ineligible for CVE assignment > + * No declaration of ``.secure`` property: follow the security > + bug process initially. The virtualization vs non-virtualization > + use case classification will be evaluated during bug triage > + to determine whether to continue the security bug process, > + or switch to the regular bug process. Should this evaluation result in a declaration of .secure? > + > Architecture > ------------
