[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() A
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API |
Date: |
Thu, 9 Sep 2021 11:28:27 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series is experimental! The goal is to better limit the
> boundary of what code is considerated security critical, and
> what is less critical (but still important!).
>
> This approach was quickly discussed few months ago with Markus
> then Daniel. Instead of classifying the code on a file path
> basis (see [1]), we insert (runtime) hints into the code
> (which survive code movement). Offending unsafe code can
> taint the global security policy. By default this policy
> is 'none': the current behavior. It can be changed on the
> command line to 'warn' to display warnings, and to 'strict'
> to prohibit QEMU running with a tainted policy.
Ok, so I infer that you based this idea on the "--compat-policy"
arg used to control behaviour wrt to deprecations.
With the deprecation support, the QAPI introspection data can
report deprecations for machines / CPUs (and in theory devices
later). Libvirt records this deprecation info and can report
it to the user before even starting a guest, so they can avoid
using a deprecated device in the first place. We also use this
info to mark a guest as tainted + deprecation at the libvirt
level and let mgmt apps query this status.
The --compat-policy support has been integrated into libvirt
but it is not something we expect real world deployments to
use - rather it is targeted as a testing framework.
Essentially I see the security reporting as needing to operate
in a pretty similar manner.
IOW, the reporting via QAPI introspetion is much more important
for libvirt and mgmt apps, than any custom cli arg / printfs
at the QEMU level.
In terms of QAPI design we currently have
'deprecated': 'bool'
field against MachineInfo and CpuDefinitionInfo types.
it feels like we need
'secure': 'bool'
field against the relevant types here too, though I think
maybe we might need to make it an optional field to let
us distinguish lack of information, since it will take a
long time to annotate all areas. eg
'*secure': 'bool'
- not set => no info available on security characteristics
- true => device is considered secure wrt malicious guest
- false => device is not considered secure wrt malicious guest
> As examples I started implementing unsafe code taint from
> 3 different pieces of code:
> - accelerators (KVM and Xen in allow-list)
> - block drivers (vvfat and parcial null-co in deny-list)
> - qdev (hobbyist devices regularly hit by fuzzer)
>
> I don't want the security researchers to not fuzz QEMU unsafe
> areas, but I'd like to make it clearer what the community
> priority is (currently 47 opened issues on [3]).
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 :|
- Re: [RFC PATCH 03/10] block: Use qemu_security_policy_taint() API, (continued)
- [RFC PATCH 04/10] block/vvfat: Mark the driver as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 05/10] block/null: Mark 'read-zeroes=off' option as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 06/10] qdev: Use qemu_security_policy_taint() API, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 07/10] hw/display: Mark ATI and Artist devices as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 08/10] hw/misc: Mark testdev devices as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 09/10] hw/net: Mark Tulip device as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- [RFC PATCH 10/10] hw/sd: Mark sdhci-pci device as unsafe, Philippe Mathieu-Daudé, 2021/09/08
- Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API,
Daniel P . Berrangé <=
- Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API, Alexander Bulekov, 2021/09/09