Brent writes in response to my earlier message:
>I guess the point I was tyring (poorly!) to make is that the security
>situation with "ftpd" should be somehow "simpler" than the situation
>with "sendmail", because in "ftpd", the security-critical decisions
>(what uid to run as, and whether or not to chroot) are made very early
>in the life of the process, while with "sendmail", they're made almost
>at the end of the life of the process (after you've decided who to
>deliver to and how; a very complex exercise).
>I'm probably wrong, but it just "feels" like security ought to be
>easier to get right for ftpd than for sendmail.
This is true, I suppose. In the example I gave of how we do
it, the security decision is made right away -- before the process is
invoked. Unfortunately, you're probably right that it's easier to
get the security right for ftpd than for sendmail. After all,
we've been working on ftpd for HOW MANY years and it still has
the occasional hole?? Perhaps sendmail will be secure before I'm
80 years old, but I'm not going to wait and see. ;)
Other examples of complex programs that run with permissions
that have traditionally been sources of security holes:
- NFS and its related tools
- rdist
- X-Windows
- editors that run with permissions (e.g.: expreserve)
Many of these programs have privileges only for the most
stupid purposes (e.g.: they need to write to wtmp or utmp) that
could be separated into modules which contain the security
critical code. Am I the only person that's bothered by the
fact that X is so badly designed that it has to run with
permissions to work? Windows systems are huge complex beasts
that should NOT need permissions other than write permissions
to /dev/fb or whatever's required to map the frame buffer
into the server's address space.
This is all somewhat of a massive digression from the
topic of firewalls, but the principles are important. Since I've
been working at a place that deals with DOD-type Security (with
a capital 'S') I've realized that there are some basic rules
that really do make sense. I'm not suggesting that everyone go
read the orange book (you'll all fall asleep) but the ideas it
embodies - the notion of a trusted computer base, that is of
minimal size and capable of being verified to achieve assurance -
that's all good stuff and it's a shame that it's ignored by most
of the folks out there writing code.
In reference to how we do FTP:
>But this presumes that you're doing ONLY anonymous FTP, right? Or do
>you do something like create a "holding" directory for each user
>somewhere under the chroot filesystem, that they own and can use to
>send and receive files via non-anonymous FTP?
Nope. If someone wants to send and recieve files they can
telnet in and push or pull them from a non-chrooted login shell.
A little inconvenient, sure. Life's tough sometimes.
mjr.
|
|
