Subject: ACL and "autogroup/class" support

From: Jim Dennis <[email-masked]>
Date: Wed, 03 Sep 1997 15:18:54 -0700

In my recent forays into using WU ftpd I came across tantalizing
references to support for "access control lists" (ACL's).  I'm
wondering if these features have been more fully developed in current
beta's (or if they were already there and just needed more documentation).

Could anyone here enlighten me regarding this?  Does wuftpd support
ACL's?  If so, how?

Another question I had amounts to this:  I misunderstood the
"autogroup" directive (ftpaccess).  What I want is to be able to 
assign someone to a group based on the "class" that they are in --
i.e. if they came from outside my domain I'd like to "classgroup" them
to "outsider"  I'd also want to provide a way to deny "outside" access to 
members of an "insider" group.  The concern here is to enforce a policy that
employees can only access their account from within the intranet --
both to discourage them from passing their password over the Internet
(knowing that most of them will use the same password for this xfer 
account as they do for other, more sensitive internal services) -- and to 
prevent them from creating a "covert channel"  (or requiring that they
act in collusion with specific outsiders in order to accomplish that).

Let me back away from these specifics for a moment to describe my
real requirements.

I need to provide an organizational file transfer point between 
employees (insiders) and external contractors/vendors (outsiders).
There is NO anonymous FTP  (in fact there is to be NO anonymous ANYTHING
at this site -- that is a key point of their computing policy).

[Please: no debates on the degree to which this policy can or cannot
be enforced in a TCP/IP intranet environment -- I'm aware of some of 
the limititation of the protocol suite -- and they aren't germaine this
this discussion]

Ideally we'd be able to set up each user with an account -- and an
easy mechanism to permit or deny each other user 'write' access to a
given directory.  Ideally this would also prevent the user from given
read access to any other users (i.e. I can specify who gets to put
stuff into my directories -- but I can't let anyone else read 
my directories or files).  Also it would be nice if filename collisions
were transparently dealt with (a la SUNIQUE -- or store with unique filename;
but without requiring client side support for this feature).   Each file
deposite (put) on the side must clearly indicate (via ownership) the 
identity of who put it there.  it would also be nice if whole directory
trees could be just "dragged and dropped" on the client side (again with
the server automagically creating a unique toplevel directory and 
populating the structure under it.

Oh, yeah!  They want it all to be accessible via standard FTP clients
(although they are willing to have the administrative (ACL's) stuff done
via HTTPS using web browsers (preferably with client-side certificates:
SSLv3).

That's the wishlist.  The key requirements are:

	No anonymous accounts
	No "public" files 
	No way for outsiders to make files visible to outsiders
	Accountability:  no way to "forge" a file as being "from"
		another account holder.

The key constraints are: 

	Must work with a variety of commonly available Windows (GUI tools).  
	Must not add any substantial administrative overhead 
		(to the sysadmins)
	Must be sufficiently easy to use that users won't be inclined to 
	bypas it (via file attachments to e-mail -- which kills their
	cc:Mail system for files of any subtantial size).

To be honest I'm not sure that any configuration of wuftpd will 
meet these requirements and constraints.  My client might be willing
to sponsor further wuftpd development (respecting the GPL, of course)
to make a set of modifications that would implement these features:
if we/I can agree on a feature set that would work and have some
assurance of timely delivery.  (Yes, I'm NOT a programmer!).

My first take on this was: 

	have them all use PGP to encrypt the files TO the intended 
	recipient.  This eliminates most of the problems since PGP's
	encryption far surpasses their confidentiality requirements
	(they're still passing the passwords of "outsiders" in
	plaintext over the Internet).  In introduces two problems:
	requiring a specific client package for all sites, including
	external and independent contractors (minor -- simple financial
	issue), and it requires that the company institute a public
	key (PK) management infrastructure (which leaves them fighting
	over SKIP/ISAKMP/Oakley, LDAP, X.500 and all sorts of other 
	thus far unimplemented/undeployed "standards").

	Personally I suspect that .ZIP with the "scramble" (encryption)
	option would be adequate -- their confidentiality requirements
	for this work are pretty minimal; the issue is more of 
	accountability and isolation from more important internal 
	resources.

Anyway, that's my problem.  I look forward to any suggestions.

--
Jim Dennis  (800) 938-4078		[email-masked]
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <[email-masked]>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A