[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: |
P J P |
Subject: |
Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API |
Date: |
Tue, 28 Sep 2021 11:39:16 +0000 (UTC) |
On Tuesday, 14 September, 2021, 07:00:27 pm IST, P J P <pjp@fedoraproject.org>
wrote:
>* Thanks so much for restarting this thread. I've been at it intermittently
>last few
> months, thinking about how could we annotate the source/module objects.
>
> -> [*] https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04642.html
>
>* Last time we discussed about having both compile and run time options for
>users
> to be able to select the qualified objects/backends/devices as desired.
>
>* To confirm: How/Where is the security policy defined? Is it device/module
>specific OR QEMU project wide?
>
>>> it feels like we need
>> 'secure': 'bool'
>
>* Though we started the (above [*]) discussion with '--security' option in
>mind,
> I wonder if 'secure' annotation is much specific. And if we could widen its
> scope.
>
>
>Source annotations: I've been thinking over following approaches
>===================
>
>1) Segregate the QEMU sources under
>
> ../staging/ <= devel/experimental, not for production usage
> ../src/ <= good for production usage, hence security relevant
> ../deprecated/ <= Bad for production usage, not security relevant
>
> - This is similar to Linux staging drivers' tree.
> - Staging drivers are not considered for production usage and hence CVE
> allocation.
> - At build time by default we only build sources under ../src/ tree.
> - But we can still have options to build /staging/ and /deprecated/ trees.
> - It's readily understandable to end users.
>
>2) pkgconfig(1) way:
> - If we could define per device/backend a configuration (.pc) file which is
> then used
> at build/run time to decide which sources are suitable for the build or
> usage.
>
> - I'm trying to experiment with this.
>
>3) We annotate QEMU devices/backends/modules with macros which define its
>status.
> It can then be used at build/run times to decide if it's suitable for usage.
> For ex:
>
> $ cat annotsrc.h
>
> #include <inttypes.h>
>
> enum SRCSTATUS {
> DEVEL = 0,
> STAGING,
> PRODUCTION,
> DEPRECATED
> };
>
...
>
>
>* Approach 3) above is similar to the _security_policy_taint() API,
> but works at the source/object file level, rather than specific 'struct
> type' field.
>
>* Does adding a field to struct type (ex. DeviceClass) scale to all
>objects/modules/backends etc?
> Does it have any limitations to include/cover other sources/objects?
>
>* I'd really appreciate your feedback/inputs/suggestions.
Ping...!?
---
-P J P
http://feedmug.com
- [RFC PATCH 04/10] block/vvfat: Mark the driver as unsafe, (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é, 2021/09/09
- Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API, Alexander Bulekov, 2021/09/09