Date: Thu, 31 Oct 1996 00:47:02 -0500 (EST) From: "Marc G. Fournier" <scrappy@ki.net> To: Mark Crispin <MRC@Panda.COM> Cc: chat@FreeBSD.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <Pine.NEB.3.95.961031003447.15243A-100000@quagmire.ki.net> In-Reply-To: <MailManager.846716705.335.mrc@Ikkoku-Kan.Panda.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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... > 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... > 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? > b) mail readers must not unlink mail files on the mail spool under any > circumstances (only very old mailer readers still do this). I use pine/imap exclusively here, so don't know the behavior of other readers... > 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). > Again, see b) > 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. > 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... > 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? > 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? > 7) [Optional] Check ownership and size of locks. > And do what? > 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. > I used to run an ISP with over 7000 users...which cretins would you like me to disallow? > 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. > so, you are suggesting that touch/<insert favorite editor here> be modified so as to not permit creating a file in /var/mail? Then again, if /var/mail is 1777, I just have to whip together a quick C program to do the same...*shrug* > 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. > And, of course, any decent system administrator knows better then to have a mail spool NFS mounted...that was one of the first things *I* learnt. IMHO, that's what software such as IMAP/Pine are designed to remedy, as with them, I *don't* have to deal with NFS mounts... > 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. > Agreed, in a sense...which, again, is why I use IMAP/Pine, as IMAP handles all the mail spool access...and, therefore, doesn't need .lock locking to deal with NFS mounted spool directories... 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? Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.95.961031003447.15243A-100000>