de5@ornl.gov (Dave Sill) (06/20/91)
In article <22940@ogicse.ogi.edu>, pochmara@ogicse.ogi.edu (John Pochmara) writes: > > This *is* a "security hole". Some directories are world > writable, have to be. ie. /tmp and /usr/tmp. >... > In short '.' should NOT be in roots' PATH and should be > at the end, if at all, is users PATH. There is a potential problem with dot in root's path that doesn't require world writable directories and isn't fixed by putting the dot at the end. Assume a user directory with the contents: Makefile atdr.c atdr.o dtae.c dtae.o dtae dtret.c dtret.o main.c main.o xfoobar etc. Now suppose the user calls up the system administrator, who is known to remain su'd to root most of the time, and requests help with make. The user explains that when he updates a file, make fails to rebuild everything it should. The admin scans the Makefile, does an ls or two, touches some files, checks the date, etc. Of course, he's careful not to run "make" or the user's program, and he's left dot out of his path. Eventually, he sees that a filename is mispelled, or that there's a missing dependency, or whatever. The user thanks him, and that's that. Right? Unless the admin happened to mistype "date" as "dtae" at some point. Here's what's in the file "dtae": #!/bin/sh mkdir /tmp/$$ cp /bin/sh /tmp/$$/a.out chmod u+s /tmp/$$/a.out if user's shell is /bin/sh then echo dtae: not found elif user's shell is Bash then echo dtae: command not found elif user's shell is /bin/csh then echo dtae: Command not found. fi Sure, that's an elaborate scenario, and it has a relatively low chance of succeeding, unless the user happens to know the what kind of typing errors the admin makes, but there's no reason why the user couldn't put copies of dtae in all of his directories, and /tmp, and /usr/tmp, etc. To be really safe, don't do anything as root that doesn't have to be and use full path names. One could even make a /r directory and link everything into it to reduce the typing overhead. E.g., # /r/mount -a -t nfs # /r/df : # /r/reboot -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
jmason2@gpu.utcs.utoronto.ca (Jamie Mason) (06/20/91)
In article <1991Jun19.191124.20380@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >Now suppose the user calls up the system administrator, who is known >to remain su'd to root most of the time, and requests help with make. >The user explains that when he updates a file, make fails to rebuild >everything it should. The admin scans the Makefile, does an ls or >two, touches some files, checks the date, etc. Of course, he's >careful not to run "make" or the user's program, and he's left dot out >of his path. Eventually, he sees that a filename is mispelled, or >that there's a missing dependency, or whatever. The user thanks him, >and that's that. Right? > >Unless the admin happened to mistype "date" as "dtae" at some point. Of course, the administator's mistake was *not* that he had "." in is path. His mistake was that he helped a user with a problem with their personal files *as root*. What he/she should have done is su'ed to the user with the problem, then used *that* shell to solve the problem. Remember that root can su to anyone *without* entering a password. By poking around the user's files *AS THE USER*, there is no chance of accidentally executing something nasty as root. In fact only *ever* execute commands as root that you really *have to*. Su to an appropriate, weaker, userid to do anything else. AND put "." last in the path, if at all. Jamie ... Lurker in the Process Table Written On Wednesday, June 19, 1991 at 10:29:38pm EDT
karish@mindcraft.com (Chuck Karish) (06/22/91)
In article <1991Jun20.023256.12713@gpu.utcs.utoronto.ca> jmason2@gpu.utcs.utoronto.ca (Jamie Mason) writes: |In article <1991Jun19.191124.20380@cs.utk.edu| Dave Sill <de5@ornl.gov| writes: ||Now suppose the user calls up the system administrator, who is known ||to remain su'd to root most of the time, and requests help with make... | Of course, the administator's mistake was *not* that he had "." |in is path. His mistake was that he helped a user with a problem with |their personal files *as root*. What he/she should have done is su'ed to |the user with the problem, then used *that* shell to solve the problem. |Remember that root can su to anyone *without* entering a password. By |poking around the user's files *AS THE USER*, there is no chance of |accidentally executing something nasty as root. I don't think this is true on systems that support saved-set-user-ID. A Trojan horse program could su back to root under some circumstances. It's often worth trying to reproduce a problem from several different logins. Problems caused by user environment settings can be difficult to diagnose. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000