Re: [PATCH <RFC> 00/15] Encode object type security status in code

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Sep 18, 2025 at 01:35:56PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:

> > It starts with QOM, adding "bool secure" and "bool insecure"
> > properties to the TypeInfo struct, which get turned into flags
> > on the Type struct. This enables querying any ObjectClass to
> > ask whether or not it is declared secure or insecure.
> 
> We should clearly document what "declared secure" actually means.
> Here's my attempt at it: supported for use cases that require certain
> security boundaries.



> 
> > By default no statement will be made about whether a class is
> > secure or insecure, reflecting our historical defaults. Over
> > time we should annotate as many classes as possible with an
> > explicit statement.
> >
> > The "-machine" argument gains two new parameters
> >
> >   * prohibit-insecure=yes|no  - a weak security boundary, only
> >     excluding stuff that is explicitly declared insecure,
> >     permiting stuff that is secure & anything without a stetement
> 
> This isn't what users need.
> 
> >   * require-secure=yes|no - a strong security boundary, only
> >     permitting stuff that is explicitly declared secure,
> >     excluding insecure stuff & anything without a statement
> 
> This would be, if it covered everything accessible at the security
> boundaries.  It doesn't for now: only QOM.
> 
> It might still be better than nothing.
> 
> However, it may well be unusable until enough of QOM is declared secure.

Right, the problem is that for a while we'll have 3 buckets of
stuff (insecure, secure and "not sure yet"), when ideally we would
only have two buckets (insecure, secure).

I agree that for people running VMs, ideally require-secure=yes is
what they should be using.

The "not sure yet" bucket is a bit like schrodinger's cat in a box.

If we only had require-secure=yes, and that was insufficient for
the user, they'd be left with no way to exclude stuff that is
/definitely/ insecure. The prohibit-insecure=yes is at least
telling them they're not using something that is a terribly
bad idea.

In practice most of the stuff in the 'not sure yet' bucket will
be stuff that you'll only want to use in combniation with TCG,
and thus your VM will be in the 'insecure' bucket anyway.

There is a 2nd less critical use case for prohibit-insecure=yes
in relation to security report triage.

If someone submits a security report and it relies on a config
that is blocked by prohibit-insecure=yes, then we can categorically
declare it out of scope for CVE handling.

Similarly the require-secure=yes is categorically in-scope.

The 'do not bucket' is where we have to do case-by-case
analysis of the reoprt to decide whether it is in scope or
not.

> What would our advice to users be?  I'm afraid something complicated and
> impermanent like "try require-secure=yes, and if you can't make it work
> because parts of QOM you can't do without are still undeclared, fall
> back to prohibit-insecure=yes, and be aware this avoids only some, but
> not all security boundary death traps in either case."
> 
> This is an awful user interface.  But it's also a step towards the user
> interface we want: a single, unchanging switch that ensures you're
> running something that's fully supported for use cases that require
> certain security boundaries.
> 
> A next step could be getting enough of QOM declared so we can move to a
> single switch, with the (hopefully temporary) caveat about "only QOM".

Maybe the right answer is to just declare everything insecure
by default and focus on just annotating stuff for the secure
bucket as quickly as possible.

The lazy option would be to take everything that is built in
a RHEL distro build and label it as secure. We know Red Hat
is already on the hook for fixing CVEs in any such component
and sending fixes upstream. So by following the RHEL allow
list initially we should be implying any new burden for the
upstream. 

That would enable require-secure=yes for a useful amount of
code needed for secure KVM guests on x86, s390x, aarch64,
ppc64 and perhaps riscv. 


> > Some questions....
> >
> >   * Is using '-machine' the right place to express the policy ?
> 
> Not sure.  The guest boundary is just one of several security boundaries
> listed in docs/system/security.rst.  Some of them aren't really about
> the guest / the machine.
> 
> Maybe -compat?  It lets you exclude unstable or deprecated bits from the
> user interface.  Feels similar to excluding insecure bits.

Oh I forgot about -compat entirely. That does indeed feel like
a better place.

> >   * Can we change '-accel help' to report 'secure' / 'insecure'
> >     as we did for '-machine help' and '-device help'.
> 
> No idea, guess it's at worst a matter of shaving the yak?
> 
> >   * Should we have 'query-devices' for QMP to allow the 'secure'
> >     or 'insecure' status to be queried for every device.
> >
> >   * Should we have 'query-accel' for QMP to allow the 'secure'
> >     or 'insecure' status to be queried for every accelerator.
> 
> I recommend qom-list-types.  Covers all of QOM, not just devices and
> accelerators.

Yep that works, and is already reporting the 'abstract' property
so putting a'secure' property alongside fits nicely.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|