Date: Wed, 30 Oct 1996 22:21:51 -0800 (PST) From: Mark Crispin <MRC@CAC.Washington.EDU> To: "Marc G. Fournier" <scrappy@ki.net> Cc: chat@FreeBSD.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <MailManager.846742911.17779.mrc@Tomobiki-Cho.CAC.Washington.EDU> In-Reply-To: <Pine.NEB.3.95.961031003447.15243A-100000@quagmire.ki.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 1996 00:47:02 -0500 (EST), Marc G. Fournier wrote: > On Wed, 30 Oct 1996, Mark Crispin wrote: > > 1) The mail spool should be on a different filesystem than other files and > > directories. > This wouldn't prevent the DoS used as an example... No, but it closes off certain other forms of DoS attack which are not necessarily obvious. It makes it impossible to hard link outside of the directory. > > 2) The sticky bit on the mail spool must be set; 1777, not 777. > This is the cause of the DoS used as an example... It does, however, prevent bad guys from deleting other folks' mail. > > 3) All users must have a mail file on the mail spool. > > a) This must be done as a consequence of account creation. > I don't believe any of the Unix variants actually do this in > their adduser, do they? Ours does. > > 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. > this would require changes to sendmail for the queuing, no? But, > if I remember right, once the mail message is passed over to mail.local, > sendmail drops it out of its queue, so mail.local would hvae to pass it > back to sendmail...I can see a 'Exceed Max Hops' condition in sendmail > rsulting here... No, the delivery agent returns with EX_TEMPFAIL. > > 5) System maintenance software should validate the integrity of the mail > > spool on a periodic basis. > periodic basis? once an hour? a day? a week? how much email as > the user lost already as a result of the DoS example given? You decide this based upon the hostility of your environment. If you really have a bad environment, you will not use a spool directory at all. > > 6) Disregard locks that are older than 5 minutes. Report when this > > happens. > > Unlink such locks, and report any failure to unlink. > Inapplicable to the example given...I think? No, this is the DoS problem that most people worry about. > > 7) [Optional] Check ownership and size of locks. > And do what? A lock isn't valid if not owned properly or non-empty, therefore scream to the system manager that somebody is playing around. > I used to run an ISP with over 7000 users...which cretins would you > like me to disallow? We run a facility with over 50,000 users. Many of the users don't use a system with a spool directory at all, because a spool directory doesn't scale. But on the systems which have a spool directory, we reduced the DoS problems to the level of noise. > > 1) Require that all programs which access the spool are privileged. > so, you are suggesting that touch/<insert favorite editor here> be > modified so as to not permit creating a file in /var/mail? No, that means making programs which access the spool run setuid/setgid. Some UNIX variants do this. > > 2) Use system call locking -- flock() or fcntl() > > The problem with this is that this does not work over NFS. > And, of course, any decent system administrator knows better then to > have a mail spool NFS mounted For what it's worth, I agree with you; NFS mounting mail spools is a terrible idea, and that is precisely why I invented IMAP 11 years ago. Nevertheless, over half of the sites I support NFS mount their mail spools. So it doesn't matter what your opinion (or mine) of NFS mounting mail spools may be. NFS mounting the mail spool has to be made to work (as best as NFS will permit). > Isn't there a contradiction here stating that NFS locking doesn't > work, so we use .lock locking, but then state that for proper security, you > should run a server like IMAP on a dedicated mail host? Basically, one hand > you are stating that NFS mail spools are bad, but for those system admin > that don't believe this, we'll support them by having .lock locking > available? No contradiction, and yes that is exactly what I'm saying. Thousands of sites are brainwashed by SUN, NFS mount mail spools, and won't change their minds. So we make it work for these guys. But that isn't at all inconsistant with saying that a dedicated mail host is the correct way to go. Anyway, with a dedicated mail host, then you really don't care what form of locking is used as long as the locking works. If the only way in is through IMAP or POP, then none of the DoS tricks work. You could have a completely open mail spool internally just as long as the front door is locked.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846742911.17779.mrc>