Xref: utzoo alt.security:1514 comp.unix.internals:231
Path: utzoo!utgpu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: alt.security,comp.unix.internals
Subject: Re: SunOS and shared libraries, security aspects
Message-ID: <4054@auspex.auspex.com>
Date: 12 Sep 90 18:35:07 GMT
References: <3991@auspex.auspex.com> <1990Sep2.093254.11284@santra.uucp> <261@aupair.cs.athabascau.ca>
Followup-To: alt.security
Organization: Auspex Systems, Santa Clara
Lines: 23

>Yes. A kludge is a kludge, and should be avoided at all costs. What we
>really need is an option to ldconfig that allows the system administrator
>to specify path components in LD_LIBRARY_PATH that will be honoured by
>setuid programs.

Yes, some mechanism such as that - which might *also* want to, e.g.,
allow the system administrator to specify path components in boring old
PATH that set-UID programs can trust - might be nice.

It would, however, *NOT* affect the problem Jyrki is discussing!  The
problem there isn't with setUID programs, it's with programs that

	1) let you run e.g. some user's login shell, under their UID,
	   even if that user's account has no password (in which case
	   it won't ask you for a password),

and

	2) pass LD_LIBRARY_PATH (or any of various other environment
	   variables, although the others can generally be reamed out
	   of the environment very early on in "main()", while
	   LD_LIBRARY_PATH is used before "main()" is even called)
	   through unmolested when running said login shells.