John: Thanks for explaining the security ramifications of this patch. I understand better now, and it sounds like we are doing the right thing.
>> 3) Even though this is TSOL related code, I don't think using "tsol" in >> the function name is a good idea. This is a general patch to tighten >> the way modules are loaded. > > Not just an issue within this patch. We are attempting to manage the > name space for the TX changes. This is a requirement by the committee. It still seems to me that we could probably rework this patch so it is more a more generic "tightening" of security that we could get upstream into the glib code if we wanted to. Perhaps this would require making it a bit more configurable, so it could work in different ways based on a configuration choice. But if we want to maintain our own TSOL patches for this, I understand the TSOL unique requirements might make this easier to manage our own patches. Brian >>> I thought I'd start you off with one of our more simple Trusted >>> Extensions patches. :) >>> >>> Please take a look at the following NEW patch for glib. >>> >>> This patch is to improve the security of the module loading aspect of >>> glib so that trusted code can not be extended by arbitrary modules and >>> left open to the case where rogue code can be inserted into a trusted >>> component. >>> >>> In a trusted multi-label session, indicated by the env var >>> TRUSTED_SESSION, glib will restrict the locations that it will accept >>> modules from by first asking the runtime linker for the information it >>> has been configured with and falling back to some default file system >>> locations. >>> >>> Thanks, >>> >>> Stephen. >> >> >
