Re: a point is being missed

[mdr () vodka sse att com (Mark D Riggins)]

I've read a little code on SVR4 to investigate and maybe help settle
this shared lib issue.

Here's what I found:
1) The LD_RUN_PATH option to the linker gives more lattitude than you
        may be aware of.

        The linker adds this path to the a.out at compile time.  The
        dynamic linker gives it precendence over any environment flags
        such as LD_LIBRARY_PATH.  So vendors could specify an
        LD_RUN_PATH of /usr/add-on/lib:/usr/lib:/usr/ccs/lib  to allow
        extensibility w/o compromising security.

        A properly set LD_RUN_PATH is as secure as a statically linked
        binary because it will resolve all libraries from trusted
        directories.  As long as all necessary libraries are present,
        there will be no means of attack.  If the hacker gets
        write-access to /usr/lib, you've been toast for a long time by
        then.

        I don't know, but assume that similar functionality exists on
        other UNIX derivatives that support shared libs.

2) setuid files are not immune from LD_LIBRARY_PATH *if* they are executed
        by the owner.  The check is not made on the file permission bits,
        it rather checks to see that getuid() == geteuid().  So if a
        daemon running as real and effective root gets its environment
        hosed, you're toast.

Also some seem to feel that read access to shared libraries is a
security problem.  Why? Aren't these readily available for inspection
on many accessible hosts?  If you see some other reason, please let me
know, I'm interesting in investigating it.

Mark Riggins
Secure Systems Engineering
AT&T Bell Labs