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