Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.windows.x
Subject: Re: Answers Re: SunOS Shared Libraries
Keywords: SunOS 4.[x] shared libraries dynamic linking searching ldconfig
Message-ID: <44974@lll-winken.LLNL.GOV>
Date: 18 Jan 90 21:59:01 GMT
References: <130216@sun.Eng.Sun.COM>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 123


| From: gingell%opus@Sun.COM (Rob Gingell)
| 
| setxid programs and dynamic linking.
| 
| The dynamic linker will refuse to use shared objects from directories
| that it does not "trust" when running a set-user or set-group id
| program.  In 4.0[.x], the implementation simply ignores the library
| search path environment variable when runing a setxid program.  The link
| editor "trusts" /usr/lib, /usr/5lib, and /usr/local/lib.  In 4.0[.x],
| there is no way to tell the linker that other directories are
| "trustworthy."  So, if you have a library that you want to have
| dynamically linked in a setxid program, it [or a symbolic link pointing
| at it] needs to be in one of these directories.
| 
| [In 4.1] There is also a change to what ld.so considers trusted, in the
| specific case of setxid programs.  What's different in 4.1 is that if a
| program is ld'ed with -L options, and then run as a setxid program, then
| the dynamic linker will "trust" all the "-L" directories.

Rob,
  Thanks for the extremely complete and clear posting on SunOS 4.X
shared library dynamic linking.  I'm sure that it will help people by
keeping them from fruitlessly pursuing incorrect notions of how SunOS 4.X
shared libraries work.  I know that it will definitely save me time, so I
thank you for that!

  However (you knew there had to be a catch to all this praise, didn't
you), I view the current behavior as a bug, and your description of how
4.1 will allow people to work around it as a hack.  The bug that I
perceive is that ld.so doesn't trust the libraries in the directories
covered by ldconfig's cache.

	[[It's also a bug that the semantics that you describe are not
	covered in any SunOS documentation that I know of, but I'm sure
	that your posting will be attached to future SunOS 4.0.X
	distributions and will be integrated into the SunOS 4.1
	documentation.]]

Since you must be root to run ldconfig, having ld.so trust ldconfig's
cache won't introduce any security holes (as long as the fact that they
become trusted is documented).

  I view your description of the SunOS 4.1 -L handling to be a hack
because it suddenly introduces a completely new mechanism to determine
trusted libraries.  Now it may be that this turns out to be The Right
Way, but I'm suspicious of any setup that requires users to deal with
multiple mechanisms to accomplish the same thing.  If nothing else, you're
asking for a lot of user grief and many calls to Sun software support.

  Personally I think Sun should unify its shared library support and
trusted library directories via ldconfig:

    1.	Since it's likely that administrators will probably want to add
	local site dependent directories to those cached by default by
	SunOS.  In order to avoid having to edit two files (/etc/rc.local
	and /var/spool/cron/crontabs/root (which, by the way, *doesn't*
	have an ldconfig entry as advertised in the ldconfig(8) man
	page)), I suggest that ldconfig acquire it's default set of
	directories to cache from a configuration file, say
	/etc/ldconfig.conf.

    2.	Since it's likely that administrators will probably want some
	of those directories to be trusted, but not others, I suggest
	that the ldconfig'uration file contain authentication information.
	A high degree of flexibility would be granted to administrators
	if they could resolve this authentication down to the individual
	library if desired.

Thus:
    /etc/ldconfig:
	# 
	# @(#)ldconfig.conf	1.1 (SMI) 1/18/90
	# 
	# Shared library cache and ``trust'' authentication configuration
	# file.  Lines consist of library or directory paths optionally
	# followed by some number of spaces and/or tabs, followed by
	# authentication information describing the level of ``trust'' for
	# the libraries (or libraries within a directory.)  Lines without
	# explicit authentication information will infer the lowest level of
	# ``trust'' authentication, FOREIGN (see below).
	# 
	# If a directory is listed here, only the libraries contained
	# directly within that directory are inferred.  That is, caching and
	# authentication are NOT inherited by subdirectories of directories
	# listed here.
	# 
	# Authentication lines for individual libraries override
	# authentication lines for the directory the libraries are found in.
	# 
	# Current authentications are:
	# 
	# TRUSTED	Libraries will be trusted for SUID and
	# 		SGID objects.
	# 
	# FOREIGN	Libraries will not be trusted for SUID or SGID objects.
	# 		Such objects when dynamically linked against FOREIGN
	# 		libraries will generate a warning and be run with
	# 		the UID/GID of the process running executing the
	# 		object.  This is the default ``trust'' authentication
	# 		if none is explicitly given.
	# 
	# library [directory]	level of trust
	# 
	/usr/lib		TRUSTED
	/usr/5lib		TRUSTED
	/usr/local/lib		TRUSTED
	/usr/local/lib/X11	TRUSTED
	/usr/new/lib		FOREIGN
	/usr/new/lib/proj	TRUSTED
	/usr/local/lib/libzap.a	FOREIGN

While this seems like a lot, it's my expectation that most of the pieces
are already present to do this: there are plenty of unused bits in
lo_unused to implement a few bits of authentication (say at least four
for future expansion) and ld.so already has to read /etc/ld.so.cache in
any case.  It would probably require relatively trivial changes to
ldconfig and ld.so to implement this.

  Alternatives to TRUSTED/FOREIGN might be "SUID", "SGID", "SUID,SGID",
and "FOREIGN" (== 0) (i.e. a set oriented authentication), etc.

Casey