I've just been reading the unix FAQ ...

I've just been reading the unix FAQ ...

Post by Jan-Piet Me » Sat, 02 Nov 1991 21:24:57




[ ... ]

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

 
 
 

I've just been reading the unix FAQ ...

Post by cameron shell » Sat, 02 Nov 1991 23:32:13




> >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 \!*"

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

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

 
 
 

I've just been reading the unix FAQ ...

Post by Man-Wei T » Sat, 02 Nov 1991 16:29:42


.... 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've just been reading the unix FAQ ...

Post by Christos S. Zoul » Sat, 02 Nov 1991 20:15:39



>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 \!*"

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,


 
 
 

I've just been reading the unix FAQ ...

Post by madhavan.srinivas » Sun, 03 Nov 1991 02:08:42



>.... 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 \!*"

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

 
 
 

I've just been reading the unix FAQ ...

Post by Mike (My Watch Has Windo » Sun, 03 Nov 1991 06:37:22


   .... 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.

 
 
 

I've just been reading the unix FAQ ...

Post by Dik T. Wint » Sun, 03 Nov 1991 10:51:10




 > >      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

 
 
 

I've just been reading the unix FAQ ...

Post by Phil McCall » Wed, 06 Nov 1991 07:17:55



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

 < 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

 
 
 

I've just been reading the unix FAQ ...

Post by David Gundla » Sat, 09 Nov 1991 01:19:27




%
% >  "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

 
 
 

1. I've read/am reading the faq's - but what is a Segmentation fault?

I am reading the faq's as fast as I can, but I would really appreciate a
pointer to information about Segmentation faults.  Every time I try to run
Pico (among others) the system responds with "Segmentation fault".  What
does it mean?  How can i fix it?  Is it in a FAQ?  Which one?

THANKS!!!
Dana
----------



----------
--
------------------------------------------------------------------------------
 \ The above does not represent OIT, UNC-CH, laUNChpad, or its other users. /
   ------------------------------------------------------------------------

2. ppp dialin with modem

3. BackSpace, Delete, Vim (I've read all the FAQ's)

4. getline cmd

5. Now that I've read the FAQ...

6. Simple C question...

7. I've read FAQ, still only get LI on boot

8. ISDN PCMCIA card in the US ...

9. gcc sig11 problem (I've read the FAQ)

10. Help, I've fallen and am accused of hacking!

11. Setup HP LaserJet4L & Slackware v2.3 (I've read the HOW TO's)

12. You've got yours, I've got mine... let the others in their shit!

13. Help with ppp....I've read all the How-to's .....