Date: Wed, 30 Oct 1996 15:05:05 -0800 (PST) From: Mark Crispin <MRC@Panda.COM> To: chat@FreeBSD.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <MailManager.846716705.335.mrc@Ikkoku-Kan.Panda.COM> In-Reply-To: <Pine.NEB.3.95.961030175425.8183P-100000@quagmire.ki.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Oct 1996 18:01:57 -0500 (EST), Marc G. Fournier wrote:
> I'd like to post something that Joe sent me, that fully cleared up
> in *my* mind why 1777 is a *very* bad thing.
Marc -
I said, very specifically, that there are steps that you need to take to
secure a public mail spool to avoid denial of service problems.
It is only when you fail to follow these steps that you have problems.
The most important of these steps are:
1) The mail spool should be on a different filesystem than other files and
directories.
2) The sticky bit on the mail spool must be set; 1777, not 777.
3) All users must have a mail file on the mail spool.
a) This must be done as a consequence of account creation.
b) mail readers must not unlink mail files on the mail spool under any
circumstances (only very old mailer readers still do this).
c) Users should be encouraged not to empty their mail files completely
(this is not an issue with modern software; the pseudo header which
maintains UID status will prevent the mail file from being empty).
4) Mail delivery software must validate the integrity of the mail spool:
a) mail files must be properly owned.
b) mail files must not be hard lunk anywhere
c) mail files must not be soft links
d) mail files must be in proper format
Any failure of any of these validation checks should alert the system
manager. Mail to that mailbox should be held in the mail queue and not
bounced.
5) System maintenance software should validate the integrity of the mail spool
on a periodic basis.
6) Disregard locks that are older than 5 minutes. Report when this happens.
Unlink such locks, and report any failure to unlink.
7) [Optional] Check ownership and size of locks.
8) Don't allow cretins to use your system. Ultimately, the more you secure
your system from the misbehavior of authorized cretins, the less usable the
system is to the other authorized users.
Protecting the mail spool is a lazy way out of doing these steps. You have
two choices when protecting the mail spool:
1) Require that all programs which access the spool are privileged.
The problem with this is that this means that J. Random User can
not write or use her own mail program -- she is at the mercy of the
system manager. It also means that every mail program is part of
the web of trust. This is unacceptable in a security environment.
2) Use system call locking -- flock() or fcntl()
The problem with this is that this does not work over NFS. Either
there is no locking at all, or you put your trust in the lockd
daemon.
Lockd does not work. It will seem to work, briefly, until you start having
cluster-wide hangs. Nobody has ever gotten lockd to work. The design itself
is flawed. The only question with lockd is how long it takes before the first
cluster-wide hang. A "robust lockd" is like cold fusion; theoretically
possible, but to date everyone who claims to have done it has been proven to
have been mistaken.
The people who are really concerned about security don't deal with mail reader
access to mail spools at all. They don't want to do the system maintenance
work of a public mail spool, nor use the unsatisfactory non-solutions of
privileged programs or system call locking.
These people do one of three things:
1) they deliver to home directories or some other directory owned by
the mailbox owner.
2) they put IMAP and/or POP between the mail reader and the mail spool
(that is, the mail spool runs on a dedicated machine that can only
be accessed via IMAP or POP).
3) they do both.
Mail reader access to mail spools is stone knives and bearskin stuff. If you
really don't care if you play ball with the other stone knife/bearskin guys,
then drop your stone knives and bearskins. Do something that doesn't require
mail readers to run with privileges. Do something that doesn't require trust
in unreliable and unportable mechanisms.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846716705.335.mrc>