* Gerd Hoffmann (kra...@redhat.com) wrote: > On Thu, Jun 24, 2021 at 04:01:25PM +0100, Dr. David Alan Gilbert wrote: > > * Gerd Hoffmann (kra...@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 / dgilb...@redhat.com / Manchester, UK