Re: [PATCH v2 12/32] docs: expand security docs with info about security status

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> 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é <berrange@redhat.com>
> ---
>  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
>  ------------