Brian, See in-line comments.
John P.S. I am on the alias. 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). It also use the crle(1)--configure runtime linking environment--via dlinfo. > 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. 3rd parties should not be installing into /usr/lib. They should be using /opt/<mummble>/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? Misunderstanding the need. > This seems like something that should be discussed a bit with ARC. It was discussed with the ARC. We had the same misunderstanding during the ARC review. This is about restricting the loadable paths to a know location of use. It is not about creating a secure library or module set. The /usr/lib and /usr/sfw/lib paths are hard coded to enable GTK+ applications to dynamically load objects in those paths without these being enabled things like Mozilla (which resides in /usr/sfw) would not even function. The crle mechanism could be used to insure that these paths are included in the runtime link environment. However, adding /usr/sfw would pose a shift in the ARC precedence of having access to the /usr/sfw WOS by default. This solution adds the /usr/sfw/lib path to only GTK+ applications so it doesn't violate the ARC precedence. Again this is all about restricting and securing. If we don't trust /usr/lib and /usr/sfw/lib then we have some serious problems. /usr/lib/security is a slightly different beast used for a different purpose. You will notice that the code calls dlinfo(). This is the C equivalent of crle. > 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. > 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. > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
