[svlug] how to allow a user to ftp but not login?

[Joey Hess]

Rick Moen wrote:
> FYI, so does pftpd, which I trust a good bit more than I do ProFTPd.
> 
> http://linuxmafia.com/pub/linux/security/ftp-daemons

I have to take issue with some things you say in there. 

[ proftpd, wuftpd ]
| Both of these are extremely full-featured, but have proven to be fatally 
| flawed from a security perspective:  They have a long history of security 
| exploits, and are considered probably hopeless in the long term.

What then, is proftpd's fatal design flaw? You never say.

Personally, I tend to trust a program after it has been thorougly
audited multiple times by multiple independant parties. Such audits
often turn up security holes, even in a design that is well thought
out from a security perspective. A "long history of security exploits",
then, does not at all imply that a program is "hopeless in the long term".
A program is "hopeless in the long term" iff it has a shoddy design.

Consider mail servers, for example. Sendmail has had a long history of
security holes. It also has a crummy design from a security
perspective: one monolithic program that runs as root. On the other
hand, postfix has a short security history. It has a very well-thought-out
design from a security perspective: multiple small programs, only one
of which requires any additional privledges.

If we lived in a world where postfix and sendmail had reversed security
histories -- postfix was the vehicle for the internet worm, and had
numerous other holes, while sendmail appeared not too long ago, and has
only had one minor security hole -- I would still pick postfix as the
more secure of the two servers. In fact, I would be more sure of its
security than I am in the real world, since in reality it hasn't been
around long, and can't have been audited a great deal.

I guess what I'm trying to say is that looking at the security history
of a program, counting the number of security holes and declaring it
"hopeless" is shortsighted. Security comes from good design, careful
implementation, and thurough auditing. Throwing a program away just as
its security holes are beginning to be fixed, and moving on to a new
program will ensure only that you are using a succession of new,
untried, and probably insecure programs.

In my opinion, proftpd is in the middle of such a series of audits. I've
seen edvidence that the implementation is not what it could be, falling
foul of many common security pitfalls of C. The authors of proftpd seem
to be commited to fixing these problems though. I look forward to the very
secure ftp client that will hopefully result after some more prodding.

-- 
see shy jo