alt%aids-unix@sri-unix.UUCP (06/10/83)
From: Howard Alt <alt@aids-unix> Lets face it, mail on Unix wasn't ment to be secure. The options people have offered so far are: 1) set /etc/delivermail suid root. 2) set /bin/mail suid root. 3) set (one or the other I don't recall) sgid a mail group. All this discussion has to do with keeping others from perusing your mail. This means that you want the mail files to be some mode that keeps others from reading your mail. The problem seems to be that they need to write into your mail file. So, how about mode 622? This allows anyone to write your mail file, and no one but you and root to read it. All of the previous ideas were based on having the file mode 0600, and in fact, all of the previous ideas would work just fine. All you would have to do is change /bin/mail so that it 1) makes the file mode 600, and 2) makes the owner of the file the person who is recieving it. I had started writing earlier, and I was going to claim that /bin/mail was an insecure program because you can do shell escapes, and write files. I was wrong. I decided to test it, and it does the setuid(getuid()) bit where it has to. So, in reality, it makes no difference if you put the setuid bit on delivermail or binmail. I hope that someone could please tell me why delivermail is an insecure program. I can't see how it can be made to do anything but deliver mail. Since it calls binmail to actually put the mail into the mail spool directory, I don't see any problems. In fact, it seems that delivermail should be the suid one. That way whatever mailer you use, it will be called by root, and you can protect your Top Secret mail. This brings up another point. If you have mail that you don't want people to read, why not send it with secret mail. In the past, every instance that I have seen of problems occuring becasue of mail poking, it has been someone who could have become root and done exactly the same thing. But, be of good cheer folks, we haven't long to wait before this whole thing gets rehashed again for the new mailsystem Sendmail. In fact, sendmail is nice. It works very well from what I have used of it. Ha, ha. Just when you thought you had delivermail figured out, here comes a new, fancy, sexy mailer with IPC and everything... What Fun! Cheers, Howard.
jdb%s1-c@sri-unix.UUCP (06/10/83)
Unfortunately, "delivermail" is insecure because it can mail to files and send mail through pipes to processes that it spawns. Causing "/bin/mail" to setuid(getuid()) before invoking "delivermail" solves some of the problems, but it doesn't solve them all (for reasons I'd rather not circulate in a public forum). It also causes some new problems of its own. Consider the case of the "msgs" program. In a hostile environment it may be undesirable to leave "/usr/msgs" world-writable (as it would also be undesirable to leave individual mailboxes world-writable, since mischievous users could corrupt or truncate them). Non-root users would then use "mail msgs" which is later aliased to "|/usr/ucb/msgs -s". In order for this to work, however, either "delivermail" (which writes to non-mailbox files and pipes) or "msgs" would have to run suid-root. Alternate examples include mailing to system log files (e.g. a "bugs" file); if the file isn't world-writable then "delivermail" must run suid-root (or at least sgid-something) to write it. It seems that a better approach would be to forbid mailing to files and (pipes to) programs unless these files and programs are specified in "/usr/lib/aliases". Thus, mailing to system-established files and programs would work, but users wouldn't be able to mail to any random target. John Bruner S-1 Project/Lawrence Livermore Lab jdb@s1-c
alt%aids-unix@sri-unix.UUCP (06/10/83)
From: Howard Alt <alt@aids-unix> Ah! I never thought of the pipe hole! Presumably though, if you are paranoid enough to go to all of the trouble to make the mail secure, you can regulate the alias file too. Howard.
Michael.Young%cmu-cs-g@sri-unix.UUCP (06/10/83)
When I was hacking for the MMDF project (part of the CSNet effort at U of Delaware EE Dept.), I ran into a fairly novel idea for writing to files/pipes/etc. Here goes: When mail is about to be delivered to a given address (user), an attempt is made to find a delivery program. [It should be pointed out that the setuid (receiver) has already been done.] First, the recipient's home directory is searched for a mail-receiving program. [If you don't like the security aspects here, require some special action to "install" a mail-receiving program, and of course assert that the receiver owns it.] If this isn't found, a default delivery program is fired up which writes your mail file. [If you like, you could add other searches for delivery programs, but it's not that necessary.] Some example activities of users' delivery programs are: 1) forwarding to a new address, and/or informing the sender of a temporary or permanent absence, 2) writing a special file, perhaps according to the contents of some header line (like "subject" or "x-filename" or whatever), 3) executing a program of one's choice. [This is what I worked on last summer -- a protected remote execution environment.] 4) Reformatting incoming mail or chopping out useless information, (perhaps the whole thing!) 5) Archiving mail, in case you accidentally delete it later, 6) Adding to bulletin boards or similar message files. The possiblities are endless. Since it's the recipient running it, he can't complain. No system administrator is required to change forwarding address, etc. If you want to allow really wierd things to happen, you could even let the recipient's program get setuid/gid to someone else. Some of the common capabilities could be offered by system programs, which users could link (symbolically, even) to, in case you're worried about zillions of disk blocks being wasted, or "insecure" copies of these things floating around. The only real disadvantage I can see is that incoming mail can end up using lots of cpu time, but even this can be limited. I don't think anyone has adequately dealt with the junk-mail problem anyway, so it wouldn't get me down yet. What do you think of this strategy? I don't see any major holes in it, and it sure was convenient (and fun to hack on, but that's not the object). It seems that making the recipient fully responsible for his mail is only reasonable, and safe. Michael
dee@cca.UUCP (06/12/83)
If UNIX had separate append permission then something like 622 for your mail file might make sense. As it is, write permission lets someone smash your mail which may be worse than someone just reading it. Donald Eastlake decvax!cca!dee
bstempleton@watmath.UUCP (Brad Templeton) (06/13/83)
Come on, guys. Mail security is not hard at all. First of all, ignore that /bin/mail calls delivermail calls /bin/mail -d This is a kludge of a high order, although not hard to get around, since you just have to split the two programs. Delivermail gets no powers. You give the delivery programs the power. This includes something like /bin/mail -d and uux (on our system uucp is secure) etc. Now, if you leave /usr/spool/mail writable so mailers can release mailboxes, you are of course leaving lots of holes. If, however you secure it and right a small utility suid to the owner of /usr/spool/mail that will release the mailbox of getuid() then mailers can call this. Voila, you are secure. There is no need to have group permissions or anything else as I see it. Mind you, why not put the mailbox in the user's directory (perhaps in a system-files directory if we can ever get one going) and avoid any problems you imagine. . -- Brad Templeton - Waterloo, Ont. (519) 886-7304
alt%aids-unix@sri-unix.UUCP (06/13/83)
From: Howard Alt <alt@aids-unix> Yes, but would you rather have them be able to selectivly change it rather than just bash it? With read permissions turned off, you can't edit the file to change things, all you can do is write a whole new one... I think I (if I were worried about such things) would rather my mail file be just bashable rather than readable, changeable, AND bashable. Continuing a pointless arguement... Howard.
scw%ucla-locus@cepu.UUCP (06/13/83)
From: Steve Woods <cepu!scw@ucla-locus>
.
.
.
It seems that making the recipient fully responsible for his mail
is only reasonable, and safe.
I would aggree with this except that it would open far more problems
than it would cure.{FLAME ON} Another objection (partially cleared up
by having 'symbolic' links to system mail utilitys) is: there are many
ignorant (may i even say dumb) users around, some of them with great
powers (like project directors), who might take great umbrage at the
loss of even 1 small memo and are not compentant to deal with ANY
programing, it is far far better to have them manually dispatch their
own mail than to have even a canned dispatcher do it.
{FLAME OFF}
I would think that limiting pipe/non_mailfile_file writes to
.../aliases specified destinations would be the best way (as long as
.../aliases is protected).ptw@vaxine.UUCP (P. Tucker Withington) (06/13/83)
The mention of user-specifiable delivery programs and the particular idea of
notifying senders of the receiver's temporary absence brings to mind an early
experience on the ARPAnet...
Supposedly two prof.'s both went on summer sabbaticle, setting their mailers
to respond to all mail with a "I'll be back in a couple of months" message.
Just to be sure, they also sent the message out immediately to all their
colleagues they communicated with frequently.
A few days later, the whole net slowly ground to a halt as it filled with:
+------------------------------
| Re your message: "I'll be back in a couple of months...
|
*I'll* be back in a couple of months.
--Tucker (ptw@vaxine.UUCP)
(I'm still here)chris.umcp-cs%udel-relay@sri-unix.UUCP (06/15/83)
From: Chris Torek <chris.umcp-cs@udel-relay> From: decvax!wivax!linus!vaxine!ptw@ucb-vax ... Supposedly two prof.'s both went on summer sabbaticle, [sabbaticAL! Ever try ``spell''? Just a nit.] setting their mailers to respond to all mail with a "I'll be back in a couple of months" message. Just to be sure, they also sent the message out immediately to all their colleagues they communicated with frequently. A few days later, the whole net slowly ground to a halt... Fortunately the MMDF auto-mail-responder notes to whom it sends its response, and inhibits further automagic replies. - Chris
smk@linus.UUCP (Steven M. Kramer) (06/15/83)
I was going to stay out of this argument, but now I can't resist.
The 'readability' of a mail file is a compromise of security (if
such things are security-relevant things on your system).
The ability of someone to rm the mail file is not a loss of security
but rather a loss of data integrity.
To fix the security problem -- make MAILMODE ~600.
To fix the integrity problem, make the mail dir 755 (root)
and define the thing that doesn't remove mail when all read
(because ucbmail is not setuid).
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!smk (UUCP)
linus!smk@mitre-bedford (ARPA)