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

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

On Thu, Sep 18, 2025 at 04:44:31PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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


> 
> By the way, two booleans is a rather awkward encoding of three states.
> What about require-secure=yes/no/feeling-lucky?  We may want something
> better than feeling-lucky, it's merely the first one that crossed my
> mind :)

Yeah, this is mostly me being lazy - by the time I realized that
an enum would have been better, I didn't want to rewrite it, so I
just sent this RFC as is.

> >> 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.
> 
> Annotating something as known insecure has value, but we can do that
> even with just one flag:
> 
>     .secure = true;
> 
> means "declared secure",
> 
>     .secure = false;
> 
> means "declared insecure", and nothing means "undecided".
> 
> Initializing .secure = false doesn't *do* anything (false is the
> default), but it would still be a fine way to annotate.

I'm fine with that, as long as we don't need to be able to
programmatically query that distinction. From an external
view, '= false' and <unset> would be undistinguishable
and both be considered 'insecure'.

It would mean we, as maintainers, would know what files
are yet to be evaluated for their security status which
is still useful.

> 
> > 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.
> 
> Do you mean no new burden?

Sigh, yes. No new burden.

> 
> > 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. 
> 
> [...]
> 

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 :|