SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) (06/11/91)
This probably isn't so mysterious, but the subject line has got to be zippy or
nobody'll read my post.
The 'login' command initializes PATH with (among other useful directories)
'.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a
security hole involving the _position_ of '.' in PATH, claiming that having
'.' first is dangerous. It doesn't say why.
These add up to something screwy with '.'. Can someone explain why root/
Joe User ought/ought not have '.' in his/her path, and if so should it be
first, last, or anywhere, and (this is the good part) why? The system is an
SGI Personal Iris, IRIX v3.3.2, if it matters.
This may well be an FAQ (the book certainly seems to think so) but I haven't
found an FAQ list. If there is one, please let me know. Thanks!
_____________________________________________________________________________
/ \
| Dave Schweisguth 5386 Yale Station 203-436-2694 |
| schdavz@yalevm.ycc.yale.edu New Haven, CT 06502-5386 |
\_____________________________________________________________________________/cgd@ocf.Berkeley.EDU (Chris G. Demetriou) (06/12/91)
In article <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: > >This probably isn't so mysterious, but the subject line has got to be zippy or >nobody'll read my post. not so mysterious...and people would probably read it...but here's a response. > >The 'login' command initializes PATH with (among other useful directories) >'.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a >security hole involving the _position_ of '.' in PATH, claiming that having >'.' first is dangerous. It doesn't say why. Having . first in a path can in fact be dangerous... Think about how commands are found by the shell, using PATH: The shell check to see if the command is in the first directory in the path. If so, it uses it. Next, it tries the second directory listed, then the third, etc. (Note that this is a simplified explanation - for non-relative paths, the shell hashes the entries in the directory, for quick lookup... but in terms of effect, the above description suffices.) Say, for example, that PATH is set so that . comes before /bin - Also, say that someone has in a directory a shell script, executable, or whatever named the same as a common command in /bin such as, say, rm. Say that another user is wandering around, looking for interesting items, and while in the directory containing rm, they say rm ~/foofile or whatever, to get rid of one of their files (legitimately). instead of /bin/rm being executed, ./rm is, because it's in the PATH first. ./rm might, for example, create a program which is set-uid to the person who ran ./rm, or might remove all the files of the person who executed it, or whatever... you can probably see how this can cause problems for normal users. Then imagine that same situation for root, and consider that in many cases, root's PATH doesn't contain all of the standard directories that a user's PATH does. Also, consider that root occasionally has to do things in other people's accounts... All a hacker needs is a few seconds with root access to make an almost-permanent breach of security (if they know what they're doing). A hacker can create such a program to do this, and can probably position it in such a place that root and/or other users will accidentally run it, and compromise their accounts (or, for root, the system). Moral of the story: (1) root shouldn't have . in his/her PATH, and (2) users should have . as close to the end of their path as possible, if at all. cgd cgd@ocf.Berkeley.EDU OCF Staff - But these words are mine, *ALL MINE*... -- < Chris G. Demetriou | "Everybody's playing the game, > < cgd@ocf.berkeley.edu | But nobody's rules are the same. > < ...!ucbvax!ocf!cgd | Nobody's on nobody's side." - Chess > <=============================================================================> < Annoyance for hire. Name a time. Name a place. Name a target. I'm there.>
mstgil@sol.acs.unt.edu (Marc Ph. A. J. St.-Gil) (06/13/91)
cgd@ocf.Berkeley.EDU (Chris G. Demetriou) writes: >In article <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >> >Say, for example, that PATH is set so that . comes before /bin - >Also, say that someone has in a directory a shell script, executable, or >whatever named the same as a common command in /bin such as, say, rm. How about 'ls' instead of 'rm'... much easier to see the danger here what's the most common command you use after changing to a new directory? ^^^^^^^^^^ a rhetorical question :) --
jonw@assip.csasyd.oz (Jon Wright) (06/13/91)
In <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >This probably isn't so mysterious, but the subject line has got to be zippy or >nobody'll read my post. > >The 'login' command initializes PATH with (among other useful directories) >'.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a >security hole involving the _position_ of '.' in PATH, claiming that having >'.' first is dangerous. It doesn't say why. > These add up to something screwy with '.'. Can someone explain why root/ >Joe User ought/ought not have '.' in his/her path, and if so should it be >first, last, or anywhere, and (this is the good part) why? The system is an >SGI Personal Iris, IRIX v3.3.2, if it matters. > Simple...... If ROOT has "." in his/her path, I create a file called "ls" in any directory that is: a. I have write permission for b. Root may use.... My ls will do the following: #!/bin/sh WHO=`whoami` FILE=/tmp/...gotcha.${WHO} echo > ${FILE} chmod ugo+rwx ${FILE} chmod ug+s ${FILE} /bin/ls $* or something similar (I don't want an arguement about the correctness of this example - the idea is right). Now I wait patiently and keep checking /tmp, eventually root will try to run ls in that directory, and bingo I now have a setuid file thta I can modify. Obviously I need to pick a command that is not built into the shell and also that appears in the path later than "." If "." is at the end, then try common misspellings of commands such as "ls-" and "act" etc. > >This may well be an FAQ (the book certainly seems to think so) but I haven't >found an FAQ list. If there is one, please let me know. Thanks! > _____________________________________________________________________________ >/ \ >| Dave Schweisguth 5386 Yale Station 203-436-2694 | >| schdavz@yalevm.ycc.yale.edu New Haven, CT 06502-5386 | >\_____________________________________________________________________________/ Hope this helps, Regards, Jon Gilbert Wright Network Manager Unix Systems Consultant Computer Sciences of Australia Guru Software Services jonw@assip.csasyd.oz gremlin@runxtsa.runx.oz
noble@ICSI.Berkeley.EDU (Brian Noble) (06/13/91)
In article <CGD.91Jun11163602@sandstorm.ocf.Berkeley.EDU> cgd@ocf.Berkeley.EDU (Chris G. Demetriou) writes: >In article <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >> >>This probably isn't so mysterious, but the subject line has got to be zippy or >>nobody'll read my post. > >not so mysterious...and people would probably read it...but here's a response. >> >>The 'login' command initializes PATH with (among other useful directories) >>'.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a >>security hole involving the _position_ of '.' in PATH, claiming that having >>'.' first is dangerous. It doesn't say why. > >Having . first in a path can in fact be dangerous... > [a good explaination of why the . first is bad deleted] > >cgd >cgd@ocf.Berkeley.EDU >OCF Staff - But these words are mine, *ALL MINE*... > The PATH = (. /bin ...) problem is only a special case of a more general problem, to wit: the thing you are executing may not be in just the place you thought it may have been. Most manual sets have a section on security (at least the SunOS one does) and they are Highly Recommended Reading (tm) for anyone who has the slightest responsibility for administering a system. One of the things the Sun manual says (which I have really taken to heart) will eliminate this strange executable location problem alltogether: always use _full_ pathnames, i.e. they start with a / and are really long. Brian noble@tenet.berkeley.edu "Just because I'm paranoid doesn't mean one of my users isn't up to something"
mal1@pyuxf.UUCP (maureen lecuona) (06/15/91)
The security hole having to do with "." being anywhere but last in the PATH is due to the following scenario: Let the following be true: PATH=.:/bin:/usr/bin:/etc and also, ls -ail /usr/admin is rwxrw-rw Now if the administrator does the following: cd /usr/admin su - Then if someone has put a trojan anywhere in the /dir which masquerades as a legitimate command, ie: df, diff, or any other frequently used command, the fake version will be used instead of the /bin or /usr/bin version, because it will be found first in the search for the executable..... Maureen Lecuona Integrated Business Solutions, Inc. 4 Spring Lane Long Valley, N.J. 07853 (908) 850-0174
james@dlss2.UUCP (James Cummings) (06/16/91)
In article <70@pyuxf.UUCP> mal1@pyuxf.UUCP (25337-maureen lecuona) writes: |The security hole having to do with "." being anywhere but last |in the PATH is due to the following scenario: | [deleted] |PATH=.:/bin:/usr/bin:/etc | |Then if someone has put a trojan anywhere in the /dir which masquerades |as a legitimate command, ie: df, diff, or any other frequently used |command, the fake version will be used instead of the /bin or /usr/bin |version, because it will be found first in the search for the executable..... Maureen, This is not what I would term a "security hole". This is quite fixable, and should be by most competent administrators. I would term this as one of many stupid (too harsh?) things that vendors of OSs do when they ship their product. Very similar to shipping the OS without a root password or any other number of vendor/administative login ids that come without a password. This I can sort of even see their point on, but again it falls to the administrator to see that these things are put in proper form before the system is given over to user consumption.
pochmara@ogicse.ogi.edu (John Pochmara) (06/17/91)
In article <319@dlss2.UUCP> james@dlss2.UUCP (James Cummings) writes: >>In article <70@pyuxf.UUCP> mal1@pyuxf.UUCP (25337-maureen lecuona) writes: >>The security hole having to do with "." being anywhere but last >>in the PATH is due to the following scenario: >This is not what I would term a "security hole". This is quite >fixable, and should be by most competent administrators. I would term this >as one of many stupid (too harsh?) things that vendors of OSs do when they >ship their product. This *is* a "security hole". Some directories are world writable, have to be. ie. /tmp and /usr/tmp. Say you create randow file in /tmp, then you cd there and do an 'ls'. And someone else has put a program named 'ls' in /tmp. And if '.' is at the beging of your path, you have just exucuted something you did not intend to execute. I would call this a "security hole". I did see how this could be seen as 'one of many stupid (too harsh?) things that vendors of OSs do when they ship their product'. In short '.' should NOT be in roots' PATH and should be at the end, if at all, is users PATH. --John Pochmara pochmara@cse.ogi.edu
sam@bsu-cs.bsu.edu (B. Sam Blanchard) (06/18/91)
In article <70@pyuxf.UUCP> mal1@pyuxf.UUCP (25337-maureen lecuona) writes: >The security hole having to do with "." being anywhere but last >in the PATH is due to the following scenario: > >Let the following be true: >PATH=.:/bin:/usr/bin:/etc > >Maureen Lecuona >Integrated Business Solutions, Inc. Here's a nice and fairly simple way to improve security. PATH=/bin:/usr/bin:/etc then, to execute something in the local directory usr ./command or a full path. Since non-standard commands as root are "evil" this occasional laps is not as hard as it may appear. If you have local commands then create /usr/local/etc and include this in your path. WARNING: do not include a : at the start or end of your PATH. try it ;-) -- B. Sam Blanchard UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!sam ARPA: sam@bsu-cs.bsu.edu 3207 W. Devon Rd (317) 741-4500 work Muncie, IN 47304
brendan@cs.widener.edu (Brendan Kehoe) (06/18/91)
sam@bsu-cs.UUCP wrote: >Here's a nice and fairly simple way to improve security. >PATH=/bin:/usr/bin:/etc >then, to execute something in the local directory usr ./command or a >full path. It took some getting used to, but after about a month I got myself into the pattern of doing this .. and have found it completely impossible to revert back. :) -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone "Ya know, kitten tacos are really better than anything you've ever tasted before!" "Oh, really." -- Rush Limbaugh
merlyn@iWarp.intel.com (Randal L. Schwartz) (06/18/91)
In article <MSH-XC+@cs.widener.edu>, brendan@cs (Brendan Kehoe) writes: | sam@bsu-cs.UUCP wrote: | >Here's a nice and fairly simple way to improve security. | >PATH=/bin:/usr/bin:/etc | >then, to execute something in the local directory usr ./command or a | >full path. | | It took some getting used to, but after about a month I got myself | into the pattern of doing this .. and have found it completely | impossible to revert back. :) I've been doing this for over three years, even with my "everyday" account. It's amazing how many "off the net" Makefiles break because they expect to be able to run a shell script named "foo" in the current directory with "foo arg arg arg". I find myself saying PATH=:$PATH make a lot. :-( Just another reasonably secure individual, :-) -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
mal1@pyuxf.UUCP (maureen lecuona) (06/19/91)
James: I agree that the "security hole" is the result of poor administrative practice, but I disagree that it is a "vendor" problem. Inasmuch as one is not buying a "turn key" application when one buys unix, and since unix presupposes some administration is being done by the purchasing individual or company, I fail to see any justification for blaming vendors exclusively. Vendors would be to blame only if the base installed system came this with system directories (/usr/bin, say) with rw permissions for all. But, as you must know, administrators OFTEN create the conditions which allow security penetration. After all, they tend to su to root all the time, and maybe they haven't taken the time to set umask before creating directories, or installing new products, or making new device nodes, etc... In any case, the "security hole" is the result of poor administration, whether it's a vendor, or a novice administrator, and this does not make this any less of a problem in my view.... M. Lecuona
les@chinet.chi.il.us (Leslie Mikesell) (06/19/91)
In article <12714@bsu-cs.bsu.edu> sam@bsu-cs.UUCP (B. Sam Blanchard) writes: >Here's a nice and fairly simple way to improve security. >PATH=/bin:/usr/bin:/etc Isn't this annoying overkill compared to just putting "." last in your path? That will prevent accidental execution of the wrong copy of standard commands while still letting you test programs in your current directory and run normal makefiles without contortions. Les Mikesell les@chinet.chi.il.us
mike@raven.bv.tek.com (Michael Ewan) (06/20/91)
In article <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu>, SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: |> |> The 'login' command initializes PATH with (among other useful directories) |> '.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a |> security hole involving the _position_ of '.' in PATH, claiming that having |> '.' first is dangerous. It doesn't say why. |> These add up to something screwy with '.'. Can someone explain why root/ |> Joe User ought/ought not have '.' in his/her path, and if so should it be |> first, last, or anywhere, and (this is the good part) why? The system is an |> SGI Personal Iris, IRIX v3.3.2, if it matters. Having . in your path (especially root's) is dangerous because someone could put a trojan horse program in / (or your home dir) that would execute instead of the system command of the same name. For example: someone could put a command in / and call it 'ls', that was acctually a shell script that did rm -fr /' you'd have a real problem. So if you have . in your path you put it last so destructive shell scripts can't masquerade as system commands. That is you'll get /bin/ls instead of ./ls. Mike -- Michael Ewan (503)627-6468 Internet: mike@tekgen.BV.TEK.COM Unix Systems Support UUCP: ...!uunet!tekgen.bv.tek.com!mike Tektronix, Inc. Compuserve: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart
asg@sage.cc.purdue.edu (The Grand Master) (06/20/91)
In article <1991Jun19.150625.17848@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: }In article <12714@bsu-cs.bsu.edu> sam@bsu-cs.UUCP (B. Sam Blanchard) writes: } }>Here's a nice and fairly simple way to improve security. }>PATH=/bin:/usr/bin:/etc } }Isn't this annoying overkill compared to just putting "." last in your }path? That will prevent accidental execution of the wrong copy of }standard commands while still letting you test programs in your current }directory and run normal makefiles without contortions. } }Les Mikesell } les@chinet.chi.il.us I don't know about you. But most of the people I know are not perfect typisdts ( ;-) ). It is not uncommon to accidently type ks instead of ls ( I have seen many people do it before ). So now what happens when someone puts a file ks in /tmp, and you do: # cd tmp # ks (woops, I meant to type ls) # ls ...... where the source for ks is something like: cp /bin/sh . chown root ./sh chmod 4777 ./sh echo ks: not found hmm. That could lead to problems (In fact I used it to break security in a system once - and it worked!). The moral to the story? Unless you are a perfect typist, or you are willing to read and re-read every line you type BEFORE hitting <ENTER>, better be safe than sorry. This message brought to you by CADIP Citizens Against Dot In PATH From: Your friendly neighborhood Bruce Varney --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
koerber.sin@sni.de (Mathias Koerber) (06/20/91)
In article <1991Jun19.150625.17848@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |In article <12714@bsu-cs.bsu.edu> sam@bsu-cs.UUCP (B. Sam Blanchard) writes: | |>Here's a nice and fairly simple way to improve security. |>PATH=/bin:/usr/bin:/etc | |Isn't this annoying overkill compared to just putting "." last in your |path? That will prevent accidental execution of the wrong copy of |standard commands while still letting you test programs in your current |directory and run normal makefiles without contortions. | |Les Mikesell | les@chinet.chi.il.us As someone else already pointed out,this still leaves the possibility of some- one creatins "ls-" in a directory, wher you might go once in a while. You might make a typo, and there it goes, trashing your disk. (more likely creating a root account first, or something else). It might even display: ls-: not found Shells which count the number of commands might let you find this, but TOO LATE.
sun@me.utoronto.ca (Andy Sun) (06/21/91)
mike@raven.bv.tek.com (Michael Ewan) writes: >Having . in your path (especially root's) is dangerous because someone could put >a trojan horse program in / (or your home dir) that would execute instead of the >system command of the same name. For example: someone could put a command in / and >call it 'ls', that was acctually a shell script that did rm -fr /' you'd have a real >problem. So if you have . in your path you put it last so destructive shell >scripts can't masquerade as system commands. That is you'll get /bin/ls instead >of ./ls. If this is really the case, I am more interested in how that "someone" can write to /, rather than my having '.' at the beginning of my path. There is obviously a bigger security hole somewhere on the system than this if some non-admin people can write to /. Andy _______________________________________________________________________________ Andy Sun | Internet: sun@me.utoronto.ca University of Toronto, Canada | UUCP : ...!utai!me!sun Dept. of Mechanical Engineering | BITNET : sun@me.toronto.BITNET
jc@raven.bu.edu (James Cameron) (06/22/91)
>>>>> On 21 Jun 91 11:15:44 GMT, sun@me.utoronto.ca (Andy Sun) said: |> mike@raven.bv.tek.com (Michael Ewan) writes: [...deleted message about having '.' in path is bad...] |> If this is really the case, I am more interested in how that "someone" |> can write |> to /, rather than my having '.' at the beginning of my path. There is |> obviously |> a bigger security hole somewhere on the system than this if some non-admin |> people can write to /. |> Andy The example of having something in / is bad for obvious reasons. But what about /tmp? A script named say "la" (common type of "ls") which does a chmod 777 /, sends mail to the person and then echos "la: Command not found" would do the job nicely. jc -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)
yeidel@tomar.accs.wsu.edu (Joshua Yeidel) (06/22/91)
>The example of having something in / is bad for obvious reasons. But >what about /tmp? A script named say "la" (common type of "ls") which >does a chmod 777 /, sends mail to the person and then echos >"la: Command not found" would do the job nicely. Is /tmp in your path? Why?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/22/91)
In article <1991Jun18.165128.10031@iWarp.intel.com> merlyn@iWarp.intel.com (Randal L. Schwartz) writes: > In article <MSH-XC+@cs.widener.edu>, brendan@cs (Brendan Kehoe) writes: [ on not having . in $PATH ] > | It took some getting used to, but after about a month I got myself > | into the pattern of doing this .. and have found it completely > | impossible to revert back. :) > I've been doing this for over three years, even with my "everyday" > account. Ditto. Usually when I find broken Makefiles and scripts I go to the trouble of fixing them and complaining to the author. For programming, putting ./ before programs in the current directory is hardly a burden, and when I want a program in my PATH it's because I want to use it from any directory---not just the current one. So I ln -s home/foo/program ~/LINKS, with ~/LINKS in my path. ---Dan
mcmahan@cs.unca.edu (Scott McMahan) (06/23/91)
In article <1991Jun21.203054.989@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: >>The example of having something in / is bad for obvious reasons. But >>what about /tmp? A script named say "la" (common type of "ls") which >>does a chmod 777 /, sends mail to the person and then echos >>"la: Command not found" would do the job nicely. > >Is /tmp in your path? Why? I wondered that myself.
jc@raven.bu.edu (James Cameron) (06/23/91)
>>>>> On 22 Jun 91 22:06:35 GMT, mcmahan@cs.unca.edu (Scott McMahan) said: Scott> In article <1991Jun21.203054.989@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: >>The example of having something in / is bad for obvious reasons. But >>what about /tmp? A script named say "la" (common type of "ls") which >>does a chmod 777 /, sends mail to the person and then echos >>"la: Command not found" would do the job nicely. > >Is /tmp in your path? Why? Scott> I wondered that myself. Why were talking about '.' being in your path. So, if your current directory is /tmp and even if '.' is last in your path.... You figure out the trojan horse here... jc -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)
junk1@cbnews.cb.att.com (eric.a.olson) (06/23/91)
In article <JC.91Jun22234051@raven.bu.edu> jc@raven.bu.edu (James Cameron) writes: >>>>>> On 22 Jun 91 22:06:35 GMT, mcmahan@cs.unca.edu (Scott McMahan) said: > >Scott> In article <1991Jun21.203054.989@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: >>>The example of having something in / is bad for obvious reasons. But >>>what about /tmp? A script named say "la" (common type of "ls") which >>>does a chmod 777 /, sends mail to the person and then echos >>>"la: Command not found" would do the job nicely. >> >>Is /tmp in your path? Why? > >Scott> I wondered that myself. > > >Why were talking about '.' being in your path. So, if your >current directory is /tmp and even if '.' is last in your >path.... > >You figure out the trojan horse here... > >jc No, I thought we were talking about using *reasonable* security measures, especially when running as root. Jamie Mason voiced my sentiments: > 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. The scenarios posted by various individuals assume at least one of the following: 1. A system directory in root's PATH is left writeable 2. Root is foolish or inexperienced enough to do more than what absolutely *requires* root privilege 3. Root is foolish or inexperienced enough to cd to do: cd dir; ls rather than ls dir hmmph. probably also does 'pwd' to make sure the 'cd' worked. I'm not advocating putting '.' in root's path. I don't. But that's because I fear unexpected consequences of running *any* random commands as root, not because I fear that somebody might leave a trojan horse in a directory.
koerber.sin@sni.de (Mathias Koerber) (06/25/91)
In article <1991Jun22.220635.17145@rock.concert.net> mcmahan@cs.unca.edu (Scott McMahan) writes: |In article <1991Jun21.203054.989@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: |>>The example of having something in / is bad for obvious reasons. But |>>what about /tmp? A script named say "la" (common type of "ls") which |>>does a chmod 777 /, sends mail to the person and then echos |>>"la: Command not found" would do the job nicely. |> |>Is /tmp in your path? Why? | |I wondered that myself. No, but if '.' is in your path, and you are in /tmp, that will do some damage. Same thing for any writable dir in your path. Maybe UNIX should have an option which lets one refuse to run a) writable scripts/programs b) setuid scripts/programs
alan@ukpoit.co.uk (Alan Barclay) (06/26/91)
In article <2007@nixsin.UUCP> koerber.sin@sni.de writes: >In article <1991Jun22.220635.17145@rock.concert.net> mcmahan@cs.unca.edu (Scott McMahan) writes: >|In article <1991Jun21.203054.989@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: >|>>The example of having something in / is bad for obvious reasons. But >|>>what about /tmp? A script named say "la" (common type of "ls") which >|>>does a chmod 777 /, sends mail to the person and then echos >|>>"la: Command not found" would do the job nicely. >|> >|>Is /tmp in your path? Why? >| >|I wondered that myself. > >No, but if '.' is in your path, and you are in /tmp, that will do some damage. >Same thing for any writable dir in your path. Maybe UNIX should have an >option which lets one refuse to run > a) writable scripts/programs > b) setuid scripts/programs Ah, so you don't want to run ps, mail or at, to name three programs which are normally setuid. Also when root a lot of programs have permissions of 7xx so almost all programs would be writable. -- Alan Barclay iT | E-mail : alan@ukpoit.uucp Barker Lane | BANG-STYLE : .....!ukc!ukpoit!alan CHESTERFIELD S40 1DY | VOICE : +44 246 214241
koerber.sin@sni.de (Mathias Koerber) (06/27/91)
In article <1991Jun26.080351.21035@ukpoit.co.uk> alan@ukpoit.co.uk (Alan Barclay) writes: |In article <2007@nixsin.UUCP> koerber.sin@sni.de writes: |>[ after the PATH=:/bin:/usr/bin security dicussion was going on for quite |> some time, deleted... ] |>No, but if '.' is in your path, and you are in /tmp, that will do some damage. |>Same thing for any writable dir in your path. Maybe UNIX should have an |>option which lets one refuse to run |> a) writable scripts/programs |> b) setuid scripts/programs | |Ah, so you don't want to run ps, mail or at, to name three programs which |are normally setuid. Also when root a lot of programs have permissions |of 7xx so almost all programs would be writable. First an addition: c) programs not owned by user Not necessarily, but as superuser I'd be greatful to an option (ENVIRONMENT- VARIABLE or so), which would make exec/sh/etc refuse to run those programs. Simply because I might mistype. Imagine: # PARANOID=4 export PARANOID ^--some kind of level here, or bitmode or ... # echo $PARANOID 4 # la -l <---- obviously a type PARANOID: /tmp/la is setuid # mail PARANOID: /bin/mail is writable # vo /etc/passwd <--- another typo PARANOID: /usr/local/bin/vo is not ownded by root # PARANOID=0 vo /etc/passwd ^--- I really want to run this.. or even # PARANOID=99 export PARANOID # la -l PARANOID: executing /u0/local/bin/la (y/n):n PARANOID: execution denied You don't have to use this all the time, but if you know you are going to do something tricky, or u suspect pitfalls, the extra help might be welcome. Mathias Koerber | S iemens | EUnet: koerber.sin@sni.de 2 Kallang Sector | N ixdorf | USA: koerber.sin@sni-usa.com S'pore 1344 | I nformation Systems | Tel: +65/7402852 | Fax: +65/7402834 I can resist everything but TEMPTATION |#include <disclaimer.h>