Subject: FTP contractor-employee xfer point

From: Jim Dennis <[email-masked]>
Date: Sat, 15 Feb 1997 23:58:33 -0800

I have an unusual configuration to cook together.

My customer wants to have a secure transfer point to allow
external contractors to xchange files with internal employees.

The customer has purchased 2 FTP boxes, which we'll call ftpin
and ftpout.  In addition they have a spare, and a router/packet
filtering system.

All are running Linux (RH 4.x with shadow the shadown suite installed
and new kernels (2.0.27).  The packet filtering system has *everything*
ripped out of the inetd.conf and most of the daemons removed from 
the /etc/rc.d/ files.  It sends mail but doesn't receive it.  No
remote access to this machine is possible (in any way that I know of).

Now I'm stuck on configuring the ftp boxes.  There will be now
anonymous FTP.  I've configured wu-ftpd and will be installing 
the beta 12 from Academ (pursuant the the SIGURG bug from 
bugtraq and (much later) reported by CERT).  I'm using WU's 
guestgroup diretive -- and putting all accounts on this machine
into one of the groups (inside or outside).

The customer wants one of these systems (ftpin) to only allow uploads
(from the outside) and downloads ONLY from a proxying host
(which their internal personnel already use for all access to 
the Internet).  

So they want me to limit the access controls based on the address 
of the connection.  For this I'm playing with the WU "class" 
directive.  This doesn't seem to be working (maybe building
the beta 12 and replacing the beta 11 that ships with RH 4.0 will
fix that).  It seems that the "class" directive is supposed to 
set users into classes based on two factors -- which "type" of 
user is it (anonymous, user, or guest) and where the connection
is coming from (using "address globs" -- similar to the patterns
in TCP Wrappers).

I'm also experimenting with the "autogroup" directive.  
I gather, from the ftpaccess man page that this is supposed to 
accomplish something like the SITE GROUP/SITE GPASS commands
(assign user the permissions of a group) based on class.
Allegedly, once I get the "class" stuff working -- this will
also work.

Finally I'm playing with the "upload" directive. Unfortunately
the "upload" directive doesn't seem to take a class parameter
(bummer).

Are you confused yet?  I am.

It seems that combining all these features together to get the
desired behavior is a bit tricky.   (We haven't even started
work on the ftpout server -- which is supposed to have an
entirely complementary role in all of this).

I guess I want it to work something like:

external user logs in.  Since he/she is a member of one of the 
"guestgroups" ftpd chroot() to our /home/.ftp/ directory -- and
then cd's to that user's "home" directory under that.  Based on
where their connection is comming from they are assigned a class
of "insider" or "outsider."  

Outsiders are allowed to upload in any of the (chroot)/home/ directories
(by WU-FTPD's "upload" directive) and they are further limited by Unix'
native permissions on those directories.  (This should limit every user
to their own directory under (chroot)/home/ -- all the chmod and SITE
EXEC commands are disabled).  In addition the filenames are limited 
such that they must start with a letter or a digit, and must contain
only letters, digits, dashes and/or dots (using the path-filter directive).
The upload directive specifies that all uploads will be owned by
some arbitrary non-ftp user ('ftpadmin' -- who is listed in the
ftpusers file) and group-owned by "insiders."  wu-ftpd will also set the
permissions of all uploads (640).

Insiders are "autogroup"ed into the "insiders" group (which allows
them to read any of the uploads.  Hmm -- is *any* employee supposed
to be able to read *any* upload?  I can use "user" permissions to 
limit access to directories -- will that be sufficient to prevent
employee A from accessing the files that are intended for employee
B?

Also these machine will allow all users to change their 
passwords via telnet.  In the /etc/passwd file all user's
shells are listed as /usr/bin/passwd.   Any known or
potential vulnerabilities in that (for the host -- we assume
that some sniffer might get a name/password combo).

Anyway -- I'm not sure what my question really is.  I'll have to 
bang on this some more and get it up and running.  If anyone has
some tips or caveats for me -- I'd be glad to hear them.

--
Jim Dennis,                                [email-masked]
Proprietor,                          [email-masked]
Starshine Technical Services              http://www.starshine.org

---

From: George Bonser <[email-masked]>
Date: Sun, 16 Feb 1997 00:34:40 -0800 (PST)

Would something like this work:

Outside users would have one directory ... in.coming that is owned by

some user and the inbound (for lack of a better name) group. The outside
users would have write access (world write) but NO READ access. (These
systems appear to be a black hole to an outside user... they can upload
files but can not see any of the files that are there)

Local users would have entries in the normal way. They would get dumped
into their home directory upon login BUT they are members of the inbound
group and DO have read access to /home/ftp/Incoming which is a symlink
from a directory in their home dir. (/home/usr1/ftp ->/home/ftp/Incoming)
and they can read all files there. They would also need write to delete
them.

Just a thought.

> some tips or caveats for me -- I'd be glad to hear them.

Intelligence can be artificial but stupidity is real.

George Bonser
[email-masked], [email-masked]