Date: Thu, 31 Oct 1996 10:17:38 -0700 (MST) From: Nate Williams <nate@mt.sri.com> To: Mark Crispin <MRC@panda.com> Cc: chat@freebsd.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <199610311717.KAA03250@rocky.mt.sri.com> In-Reply-To: <MailManager.846716705.335.mrc@Ikkoku-Kan.Panda.COM> References: <Pine.NEB.3.95.961030175425.8183P-100000@quagmire.ki.net> <MailManager.846716705.335.mrc@Ikkoku-Kan.Panda.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. The directory is 1777 as already stated, but if you pre-create mbox's the sticky bit is not really an issue. > 3) All users must have a mail file on the mail spool. > a) This must be done as a consequence of account creation. This assumes an 'adduser' shell, which most commercial unices don't allow you to customize easily or you have to build from hand. (Solaris, SunOS, SCO are known). > b) mail readers must not unlink mail files on the mail spool under any > circumstances (only very old mailer readers still do this). Very modern mail readers do this as well when the box is empty. VM, mush, mailtool, etc... > 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). This is similar as b. By making sure a user doesn't empty the mailbox the reader won't unlink the mail file unless it's 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. You're now getting outside of the scope of the discussion. Most of these are *NOT* necessary to get email on a system. If you're *paranoid* about email they are good, but if you're paranoid you setup the directory 755 and most of the above issues go away simply because they "can't happen". > 5) System maintenance software should validate the integrity of the mail spool > on a periodic basis. If the mail spool is un-writeable, then the only thing writing to it is the system or individual mail-readers, which are all running as the user. Assuming the mail readers 'Do the Right Thing', then if the mailbox is screwed up it's the users fault. > 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. Geeze, I guess that none of us would have ever learned anything. Most folks learn by experimenting with things, and what you might consider 'cretin' behavior is just someone trying to figure things out. In any case, this discussion goes *way* beyond getting IMAP working on FreeBSD, and is your solution to 'email problems' on all system. This is *beyond* the scope of what the FreeBSD project can do, and has been already discussed many times *most* of the security problems you point out above are already fixed in a *much* better way than in your proposal, by simply not allowing folks to mess around in /var/mail except on their mboxes. If they screw them up then it's their own fault they lose mail. We're not in the business of protecting people from themselves, as no other OS does that either. > Protecting the mail spool is a lazy way out of doing these steps. It's the *safest* way of doing these steps. You've removed almost all of your steps above. It's called the 'path of least resistance', and most folks who have jobs encourage such behavior. "Let's see, I could do 50 tasks to solve the problem, or I could do 1 task which would remove 45 items from the list. Gee, I think I'll do all 50 instead, since I *love* to do lots more work." > 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. *NOTHING* works reliably over NFS. *NOTHING*. Give me an NFS system on *ANY* OS and I can break it by simply getting FreeBSD email, which is about 200-500 messages/day. If you mount your email over NFS, you're going to lose. By it's design NFS doesn't guarantee anything that you can rely on. You can argue all day with me but both my experience and lots of *really* smart folks can prove otherwise. > 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. Any kind of NFS locking simply won't work. You can't guarantee me that all of the clients and servers will be synchronized. Read the SPEC. It's not possible, although there are features that minimize the race conditions. But elimination of them w/out lockd is impossible (see above discussion of lockd). In any case, this discussion is futile, as logic isn't the reason for this discussion. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610311717.KAA03250>