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.
