Subject: Re: several messages
To: Paul Goyette <paul@pgoyette.bdt.com>
From: Curt Sampson <cjs@portal.ca>
List: tech-security
Date: 03/28/1997 09:15:29
Ok, here's my response to the first round of comments. I'd also
like to note that jon@oaktree.co.uk found a small memory leak that
I'd left in (I wasn't freeing the argument to some commands if it
was one the anonymous user wasn't allowed to execute); I've fixed
this in my copy of the patches.

On Fri, 28 Mar 1997, Paul Goyette wrote:

> Why not keep the current behavious as default, and have ann /etc/ftpd.conf
> file in which the CMASK value can be specified?

I'm really trying to avoid creating configuration files or anything
like that here. I'm attempting to bring our ftp daemon to the point
where allowing uploads is usable for Internet-connected machines
(it currently isn't), rather than trying to duplicate wu_ftpd.

On Fri, 28 Mar 1997, Perry E. Metzger wrote:

> I feel uncomfortable depending on the group stuff to protect
> permissioning. I'd very strongly prefer 777. If it becomes a
> management headache, the people running the ftp account can always
> build a cron job that moves incoming files into an examination area
> and changes the protection to something reasonable.

As David Holland pointed out, such a script itself can be a security
hole. And at this point, I have no intention of writing one to be
included with our ftpd.

I'm not sure what makes you feel uncomfortable about the permissions.
If you just make `wheel' own that directory, you've made it pretty
darn secure. If you need even more than that (though why you would
have users in wheel who can't su, I don't know) you could create
a new group with no members.

However, though I don't want to change the default anonymous umask,
I do think it's reasonable to make the anonymous umask a command
line option, so those who want a umask of 777 can avoid recompilation.
How does that strike you?

On Fri, 28 Mar 1997, David Holland wrote:

> In my opinion the best possible scheme would be an upload directory
> owned by the maintainer account, world-writeable, and sticky. Then you
> arrange to have uploads chowned to the maintainer (and chmod'd to 644
> or 600.)

This doesn't work, because it allows any user on the system to make
files available to the entire outside world via ftp. With ftp owning
the directory only the ftp user can put files there, presumably
only by using anonymous ftp, which, with my modifications, lets
you control the umask those files get.

> I don't think it's a particularly good idea to have the upload
> directory owned by ftp, even if ftpd disallows dangerous commands;
> it's easy to forget to disable something, and if not that, then some
> bug or clever trick is bound to come up that permits ftpd to perform
> some of these operations after all.

Well, having ftp own the directory is how we do things now, so at
this point even just disabling those commands is improving security.
As well, the number of operations that can act on a directory is
fairly limited anyway, and it's even further limited by what ftpd
can do (no mknod, for example).

> Fundamentally though, ftpd itself should support various upload
> directory management techniques and not hardwire any particular setup.

Perhaps. I'm really not wanting to turn our ftpd into wu_ftpd, however.

>  > Very good, but you should also prohibit directory creation as well.
> 
> Yes, but as a config option.

Again, I want to avoid multiplying config options. Directory creation
by an anonymous user under this scheme is pointless, but not harmful
as far as I can see. I think it should be left on so that those
who are not on the Internet and want a really `open' ftp site can
still have (most of) the old behaviour, just by changing the
anonymous umask.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.