Daniel P. Berrangé <[email protected]> writes:
> On Thu, Sep 18, 2025 at 01:35:56PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <[email protected]> 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.
Yes. I mentioned this fallback below.
> The prohibit-insecure=yes is at least
> telling them they're not using something that is a terribly
> bad idea.
It rules out known bad, but not "maybe terribly bad, we just don't
know".
> 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.
Yes.
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 :)
>> 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.
> 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?
> 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.
[...]
