Brian, Thanks for your comments. I believe I may have not explained the purpose and/or operation of this patch correctly. I have cc'd John Fischer the original author of the patch in case he would like to add some comments to those below.
The locations are not hard coded; look at the patch again. It requests the information from the runtime linker and only falls back to hard coded directories. See crle(1) and dlinfo(3C). So this is fully configurable as it is meant to be on a Solaris system. Perhaps we need some #ifdef SOLARIS preprocessing before we push this upstream. Note that this patch is about restricting the module loading to trusted locations. Third parties do not install software on your system. Only trusted/authorised users of your system can do that. If you install GTK_MODULES into a trusted location (either one of our defaults or one you configure with crle(1)) then you had better TRUST it. This patch stops rogue user code (or indeed rogue users) from manipulating the users environment to load arbitrary code into otherwise trusted applications. It stops users (or rogue code) from loading an untrusted gtk module from their home directory for example. This has already been discussed at ARC and with Gary Wininger in particular. As you know John Fischer sits on LSARC and he wrote the code :) Your points about the choice of code trigger and function names are good ones and something that would indeed need to be addressed for this patch to be accepted upstream. John, I would like you to look at this please and consider submitting a generic (or suitably abstracted) solution to the GLIB maintainers. Thanks, Stephen. On Wed, 2006-11-01 at 18:02, Brian Cameron wrote: > Stephen: > > I have some issues with this patch. Some of this is just my opinion > and not saying you need to change anything if you disagree. > > 1) Making the module loading more secure seems like a generally useful > feature to the glib library and not TSOL specific. However, the > way it is coded (with /usr/lib and /usr/sfw/lib hardcoded, it isn't > configurable. Perhaps if the patch were modified to check a system > configuration setting to see if it is in "tight security" mode and > then the list of secure directories should be configurable as well. > With these improvements, the odds of getting it upstream would be > better because the default configuration could be to have this > feature off (for same behavior by default). > > 2) Why are /usr/lib and /usr/sfw/lib considered the "secure diretories"? > They aren't particularly secure, many 3rd-parties install to > /usr/lib. > > Doesn't Solaris reserve /usr/lib/security for libraries that > have some degree of security concern/review. These are the libraries > that should be used when in "tight security" mode? If we aren't > installing GTK_MODULES that we require to /usr/lib/security, then we > probably should. At the very least we should install them to a > private directory rather than a public one like /usr/lib. This is > because any module can easily snoop on any user process if it is > running in the Xserver. So, using a public library directory here > isn't really so secure. > > If we want people to load GTK_MODULES in their TSOL session, wouldn't > it make sense to make people put these modules in /usr/lib/security > to ensure that only those libraries which have had some security > review can be loaded? > > This seems like something that should be discussed a bit with ARC. > > 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. > > 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. >
