blue@altger.UUCP (blue) (12/10/88)
I noticed that on many Sys V systems, /usr/spool/mail is left writable while contained mails are not readable~r . Well, this solves the problem of privacy, since on many systems while you run a sub shell from the mail (read) command you get mail privileges . Now, suppose i want to read other's mail. I can't now. All i can do is delete or write on their mailbox. I could remove the whole spool dir, but no way of reading. What about writing the "Forward to" inside those nice files? Is there a way of disabling such option? Anyway, this does not work on my xenix. It should, however, on Altos. so everyone can read other's mail. Great. -- Mr. BlueBoy, DTE222 Usenet: blue@altger | Sorry all of my disclaimers were Subnet: blue@i2ack | infected by a virus 3 minutes ago.
debra@alice.UUCP (Paul De Bra) (12/11/88)
In article <1215@altger.UUCP> blue@altger.UUCP (blue) writes: >I noticed that on many Sys V systems, /usr/spool/mail is left >writable while contained mails are not readable~r . >Well, this solves the problem of privacy, since on many systems >while you run a sub shell from the mail (read) command you >get mail privileges . >... What you describe is clearly buggy behaviour. Fortunately some mailers do better: 1) mail should be suid root, to be able to become the user who invokes it before entering a sub-shell (or an editor). 2) /usr/spool/mail/should NOT be writable by everyone. However, on many systems that do take this approach all mail is readable by everyone. There is no mail privacy imposed by the system. (though you cannot write in other people's mailbox other than by sending them mail) Though you may not like this I feel it is not a bug but a feature. One can read other people's mail but shouldn't. (Just like you can spread worms but shouldn't) If you really want secret mail, there always is secretmail (for sending and receiving encrypted mail). It is useful and legitimate to use read-access to someone's mail-file if 1) he/she requests you to do so (like to check for a message while being at a conference) 2) he/she wants you to uucp or mail the file to another site (where he/she can read it). This can be more useful than installing a forwarding address if the person wants a copy of incoming mail to remain on his/her machine. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (12/12/88)
In article <8515@alice.UUCP> debra@alice.UUCP () writes: < In article <1215@altger.UUCP> blue@altger.UUCP (blue) writes: < >I noticed that on many Sys V systems, /usr/spool/mail is left < >writable while contained mails are not readable~r . < What you describe is clearly buggy behaviour. Fortunately some mailers < do better: < 1) mail should be suid root, to be able to become the user who invokes < it before entering a sub-shell (or an editor). ARRRGH!!! NO!! NEVER!!! Mail never needs to be root! Major security hole!! It's been done before and abused and cracked before, and I don't believe it'll be safe if you do it again. It's too easy to lie to a mailer, and if the mailer can do anything as root you can become root. The standard System V behaviour is to have /bin/mail setgid mail, and /usr/mail and the mail file writable by group mail. All it needs to do is setgid(getuid) first when reading mail, and make sure to open for append-only when sending mail. The only time it might be fun to have setuid(root) is to get setuid(recipient) for smart mail-receivers, and I'd really rather not have anyone send me mail that does what they want with my userid, thank you! It's dangerous enough to have "Pipe to whatever" running as uucp or whoever your mail daemon runs as. Maybe make /bin/mail setuid=nobody setgid=mail where "nobody" is a uid with shell=/bin/sync and home directory /tmp. blue@altger.UUCP again: < >Well, this solves the problem of privacy, since on many systems < >while you run a sub shell from the mail (read) command you < >get mail privileges . Not on vanilla SVR2. I can't read root's mail, and I can't subshell out as group mail. (Note that if you have /usr/spool/mail, it's not standard System V; 4.1BSD did it, some vendors may do it, it looks more consistent and it's certainly how I'd do it if it were up to me, but System V uses /usr/mail, not /usr/spool/mail.) (Blue then goes on to describe the problem that the mail directory is 777, so anybody can trash other peoples' mail; this was either for a Xenix or an Altos? Try setting /usr/spool/mail or /usr/mail 775 uid=bin gid=mail /bin/mail 2755 (setgid, not setuid) uid=bin gid=mail and see if your system can still do mail. And rag on your UNIX vendor. Bill -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # # News. Don't ask me about News.
news@osiris.UUCP (Phil Kos) (12/14/88)
In article <355@skep2.ATT.COM> wcs@skep2.UUCP (46323-Bill.Stewart.[ho95c],2G218,x0705,) writes: >In article <8515@alice.UUCP> debra@alice.UUCP () writes: >< 1) mail should be suid root, to be able to become the user who invokes >< it before entering a sub-shell (or an editor). > >ARRRGH!!! NO!! NEVER!!! Mail never needs to be root! Major security hole!! Quite true, it is not necessary to be root to do this. If mail's real uid is still the user, the child process can set its effective uid equal to its real uid (but not vice versa, according to our local setreuid(2) manpage - only root can set real uid = effective uid). Follow least privilege and DON'T make mail setuid root. Phil Kos uunet!pyrdc!osiris!phil The Johns Hopkins Hospital, Information Systems