SunOS and shared libraries, security aspects

[BURNS,JIM]

in article <1990Sep2.093254.11284 at santra.uucp>, jkp at cs.HUT.FI (Jyrki Kuoppala) says:
> So, anyone see somthing wrong with the solution: We write a kludged
> setuid() to unsetenv LD_LIBRARY_PATH and distribute it with
> instructions of how to install it in your machine's shared library.
> We also find out which staticcally-linked programs have the problem
> and instruct users to recompile them and distribute fixed binaries for
> binary-only users.

If I've followed this correctly, the problem is not that 'login' sets uid=
euid, since 'login' is set-uid to root (which has been complained about
previously in this thread) and login certainly isn't setting uid=root.
It's setting uid= to the uid field of the record in /etc/passwd that you
supplied the correct account & password for. Of course, 'login -p' could
still pass a Trojan Horse library in to a relatively more privileged
account that you DO know the password for (as opposed to your suggestion
that the privileged account has no password - a definite no-no in the
first place.) (I would imagine that 'su' w/o the '-' would work the same
way.) Presumably then 'login' has to set uid=setuid(found uid),
and THEN set euid=seteuid(uid). The reverse order wouldn't work, since if
euid was no longer root, then setuid() would fail. Your suggestion then
that, since euid=root!=uid before the setuid(), setuid() should unset
LD_LIBRARY_PATH would appear to work. However, getting all those users to
recompile or download their binaries is a bit of a problem. How many
machines at your site don't even run the latest version of the OS, let
alone have the latest patches? And who's going to determine which of those
"statically-linked programs" needs to be re-compiled? The vendor? In what
year?
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a at prism.gatech.edu