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