. in $path

Robert G. Brown rgb at PHY.DUKE.EDU
Fri Apr 13 01:36:28 AEST 1990


That one is an easy one.  IF you leave . in your path as root AND
if a clever, malicious user exists on your system THEN they can,
in principle, do something like create "Trojan Horse" versions
of things like su or ls in their home directories.  IF you should
ever be (as root) in their home directories and use one of these
commands, THEN they can do anything at all they wish with root
privileges, including replacing the real su command and/or login
command with ones that mail copies of the user passwd's every
times someone logs in to the malefactor.

It is actually sufficient to simply put the . LAST in the root
path, at least for a "low security" system where you "trust"
most of your users.  In that way, you will always execute the
real binary first even if a user has left a TH.  They can always
leave mistyped traps (sl for ls, us for su) but their odds of
success go way down and besides, in a department (as opposed to
a "public" facility) who is going to try this anyway.

Along the same lines, members of wheel should NEVER su to
root anywhere except in a "neutral" directory (like /usr/bin
or /etc) where a user would already have to have been root
to leave a TH or in their own home directory.  This is
because . is traditionally the first directory searched on
a users path, and if Joe Administrator, as himself, tries to
su to root in Harry Hacker's home directory then he really
will search Harry's directory for a version of su first.

I personally used to leave it last, but now I have removed it
on general principles.  It isn't that big a deal to type
./command
instead of
command
on the few occasions I execute a script or binary not already on
the SAFE root path.

	Dr. Robert G. Brown 
 	System Administrator 
 	Duke University Physics Dept. 
 	Durham, NC 27706 
 	(919)-684-8130    Fax (24hr) (919)-684-8101 
 	rgb at phy.duke.edu   rgb at physics.phy.duke.edu



More information about the Comp.sys.sgi mailing list