Subject: Re: dir command

From: Tim Capps <[email-masked]>
Date: Fri, 19 Jan 1996 13:42:50 -0800

>FTP isn't something that you should just jump into and hope that it works.
>If you are working this way, you may be in for a big suprise when your
>machine gets broken in to.

Oh for crying out loud, I'm getting really sick and tired of all you
clever experts who undertstand security issues and so forth better than
the rest of the universe.  For the record: I have been working with computers
for 18 years.  I have implemented O/S level security systems, written
encryption systems, worked on firewalls, you name it.  

This is the last time I'm going to say this, and I'll really be impressed
if somebody actually reads this and finally understands what I'm saying:

dir does the same thing as ls, with a different report format.  ls is
built in to wu_ftpd.  My assertion is that dir should be also.  It is
not difficult code, and there is no reason I can think of that it can't
be put in there.

Several people (including myself) mentioned that it is difficult to get
dir working.  You primma donnas replied with "oh well, you just don't
understand security".  This is NOT a security issue!!  It is difficult
to get external programs to run - it is NOT difficult to prevent people
from running external programs.  You are looking at the wrong side of
the coin.

I cannot believe that putting the code for DIR into wu_ftpd is all that
hard, and I can't see how that causes security problems at all.  If it
does, then I want the code for LS removed, as it must cause the same
security holes.

Reading the docs and setting up the directory trees is fairly straightforward
and therefore it is fairly easy to get the system secured.

> O'Reilly's books are a good
>start, and they could have answered a lot of your questions. 

No they did not.  The problems involved with getting "dir" to work on
a system (and by extension tar, gzip and whatever) have to do with system
dependant stuff like dynamic libraries which need to be there, in the
SunOS case, some kind of library cache file, and a varying amount of
"system" directories in the ~ftp tree.  O'Reilly does an admirable job
of documenting how all  this works, what the security considerations are,
and how to best go about approaching a good solution.  They do not
go into the minutae of detail required to get "dir" running on every
system on the planet, and no one could expect them to do that.

>WU-FTPd is not
>your basic Word-Processor.

Really?  What a revelation.

>If you want functionality right out of the box, you shouldn't be working
>with freeware FTPd daemons. You should be working with a company like
>Microsoft which provides an FTP daemon for NT that is simple to get up and
>running.  

Not a useful suggestion (condecension aside) at all.  We run a unix shop
and have no interest in MicroSloth products.

>Get the O'Reilly books. It took me one day to get the server up and running
>after I downloaded, but it took me 10 days to test it before I risked
>putting my machine on the net.

Then your machine was not a SunOS 4.1.4 Sparc.  You lucky person.

Cheers,
Tim

---

From: Mitch Wright <[email-masked]>
Date: Fri, 19 Jan 1996 23:54:13 -0800

/* Tim Capps [[email-masked]] writes: */

>built in to wu_ftpd.
I'm sure Tim knows this already, but for the benefit of others that might
not... NLST (aka ls) does indeed use the internal routine send_file_list()
to provide a simple directory listing.  HOWEVER, when supplied with any
options is behaves much like LIST (aka dir) and calls /bin/ls to do the
dirty work.  Anyway...

>My assertion is that dir should be also.  It is
Except that you'd be adding ALOT of extra code to ftpd.  Sort of against
the UNIX philosophy, IMO.

>from running external programs.  You are looking at the wrong side of
You are right, however, it is more *worth while* to create an environment
such that the external programs can be invoked in a secure manner.
Again, IMO.

>hard, and I can't see how that causes security problems at all.  If it
It's trivial actually.  In a nutshell, just take the "useful" functions
out of GNU ls and put it into ftpd and make send_file_list() AND
ls_long() + ls_short() call them instead.

It shouldn't cause any more of a security problem than calling /bin/ls.
Heck, it should be less of a problem.  The only issue I see is that it
bloats wu_ftpd even more which makes things like code reviews and alike
more difficult for those that even do such things anymore.

It's also more maintenance for the software which in turn could cause
security problems due to lack of attention in other areas.  I put the
emphasis on "could" and certainly won't say "will".

>dependant stuff like dynamic libraries which need to be there, in the
Of course, but again, if you *really* wanted to incorporate them in you
could just by taking the appropriate subsets from things GNU ls and so
forth.  They've (FSF) spent alot of time making those tools work on a
variety of systems.

Personally, I prefer ftpd to be smaller and use "outside" tools where
appropriate.  I made hacks into beta-6 so it could use the TIS fwtk
authserv daemon and thus get SKEY, SNK, and various other support
for authentication.  This technique, while allowing ftpd proper to
be smaller really just spreads out the vulnerabilities a bit.
I suppose one should just say "pick your poison".

-- 
do svidaniya,

  ~mitch

Mitch Wright
[email-masked]