[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 00/34] modules: add meta-data database
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH v4 00/34] modules: add meta-data database |
Date: |
Thu, 24 Jun 2021 19:02:53 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
* Gerd Hoffmann (kraxel@redhat.com) wrote:
> On Thu, Jun 24, 2021 at 04:01:25PM +0100, Dr. David Alan Gilbert wrote:
> > * Gerd Hoffmann (kraxel@redhat.com) wrote:
> > > This patch series adds support for module meta-data. Today this is
> > > either hard-coded in qemu (see qemu_load_module_for_opts) or handled
> > > with manually maintained lists in util/module (see module_deps[] and
> > > qom_modules[]). This series replaced that scheme with annotation
> > > macros, so the meta-data can go into the module source code and -- for
> > > example -- the module_obj() annotations can go next to the TypeInfo
> > > struct for the object class.
> >
> > So this is slightly off-topic for the series; but kind of relevant,
> > but...
> > Is there a way to inhibit module loading after a given point?
>
> We could block loading after machine initialization.
> Has implications for hotplug though.
Yes; I was thinking perhaps a command to explicitly disable autoloading
if people worried about it.
> > I ask, because there's a fairly well known security escalation that
> > takes advantage of NSS loading of PAM modules; typically you have
> > your nice sandboxed application, you write out your nasty .so into the
> > sandbox and then somehow get your application to trigger the PAM module
> > load.
> > Now, what stops the same attack here?
>
> Placing a new .so at some random directory wouldn't work, qemu only
> loads modules from the search path (but I guess the same is true for
> pam).
Yes, I'm failing to find the CVE I vaguely remember about the details of
how it was messed up.
Dave
> With this patch series applied all modules are listed the in modinfo.c
> database (even if we don't have any metadata about them), so we could
> easily limit loading to modules known at compile time. Not sure how
> much that alone would improve security though, when the attacker is able
> to write to the qemu module directory it isn't much of a problem to just
> overwrite one of the existing modules.
>
> We could try work with hashes or signatures stored in modinfo ...
>
> take care,
> Gerd
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- [PATCH v4 31/34] usb: drop usb_host_dev_is_scsi_storage hook, (continued)
- [PATCH v4 31/34] usb: drop usb_host_dev_is_scsi_storage hook, Gerd Hoffmann, 2021/06/24
- [PATCH v4 30/34] monitor: allow register hmp commands, Gerd Hoffmann, 2021/06/24
- [PATCH v4 33/34] usb: build usb-host as module, Gerd Hoffmann, 2021/06/24
- [PATCH v4 32/34] monitor/usb: register 'info usbhost' dynamically, Gerd Hoffmann, 2021/06/24
- [PATCH v4 34/34] monitor/tcg: move tcg hmp commands to accel/tcg, register them dynamically, Gerd Hoffmann, 2021/06/24
- Re: [PATCH v4 00/34] modules: add meta-data database, Dr. David Alan Gilbert, 2021/06/24
- Re: [PATCH v4 00/34] modules: add meta-data database, Jose R. Ziviani, 2021/06/24