grg@berlin.acss.umn.edu (George Gonzalez) (01/26/89)
I have a question for you A/UX gurus. On our A/UX system all the mail files have too many permissions: i.e.: -rw-rw---- gus -rw-rw---- harry We'd rather have the files be -rw-------, i.e. only accessible by the owner. Don't suggest chmod 600 *, as the mail file gets deleted when you read all your mail; when recreated it gets -rw-rw----- mode again. The A/UX hot line re-created the problem on their system. This was the first time they had heard of this. They didn't have an answer either. Any ideas?
rob@pegasus.ATT.COM (rob) (01/27/89)
From article <289@berlin.acss.umn.edu>, by grg@berlin.acss.umn.edu (George Gonzalez): > > I have a question for you A/UX gurus. On our A/UX system all the mail > files have too many permissions: i.e.: > > -rw-rw---- gus > -rw-rw---- harry > > We'd rather have the files be -rw-------, i.e. only accessible by the owner. > > Any ideas? Typically the second set of permissions (group) is to let the mailer, which doesn't run with your uid when delivering mail from someone else, deposit mail into YOUR mailbox. If the group id of your mailfile is 'mail', then your mailbox is secure as long as nothing other than the mailer is allowed to run with gid == mail. If you did as you suggest and dissallow access to you mailbox from anyone (or thing) that isn't you, you won't get any messages delivered.... .....rob
antonio@Apple.COM (Antonio Ordonez) (01/27/89)
In article <289@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes: > > I have a question for you A/UX gurus. On our A/UX system all the mail > >-rw-rw---- gus >-rw-rw---- harry > >We'd rather have the files be -rw-------, i.e. only accessible by the owner. > >The A/UX hot line re-created the problem on their system. This was the >first time they had heard of this. They didn't have an answer either. > >Any ideas? FYI : We at the Hotline loked at the source and found the place where the file was created with 660 access. We have escalated the problem to A/UX engineering and will hopefully get a binary that solves the problem in the near future. ---------------------------------------------------------------------------- #include <disclaimer.h> /* I'll think of a better one later */ Antonio Ordonez amdahl \ Technical Communications/Direct Response Center pyramid!sun - apple!antonio Apple Computer, Inc. (408) 996-1010 decwrl / ----------------------------------------------------------------------------
john@unisoft.UUCP (John Sovereign) (01/27/89)
In article <289@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes: >mail files have too many permissions: i.e.: > >-rw-rw---- gus >-rw-rw---- harry > The "feature" is the local mail delivery agent, /bin/mail, which is forcing the modes that you observe. As a security feature in System V, /bin/mail is intended to be set-group-id (and not set-user-id root) and the files in the spool directory, /usr/mail, must be writable by the group. Since /bin/mail does not have the set-group-id bit set on A/UX, the group id of the mail file(s) are set to the group id of the sender whose mail happens to create the recipient's mail file. >We'd rather have the files be -rw-------, i.e. only accessible by the owner. > >Any ideas? I haven't tested either of these very thoroughly, but here goes. (1) This is a quick fix which I believe addresses your concern, but does not solve some other problems which also exist with forwarding of mail. # chmod 731 /usr/mail This change will prevent people from reading anyone else's mail file. Make sure that the directory is writable by the group "bin"; this allows "mailx" (what AT&T calls Berkeley Mail) to remove mail files by invoking /usr/lib/mailx/rmmail (another set-group-id security feature!). (2) This is more involved, but is probably the "right" fix. Add an entry to /etc/passwd with a login name of "mail" and user and group id of 6. Add an entry in /etc/group for "mail" as well. Then do the following. # chgrp mail /bin/mail /usr/mail /usr/lib/mailx/rmmail # chmod 2755 /bin/mail /usr/lib/mailx/rmmail # chmod 775 /usr/mail I'm probably forgetting something at this hour, but it's worth a go. John Sovereign UniSoft Corporation uunet!unisoft!john
domo@riddle.UUCP (Dominic Dunlop) (02/01/89)
In article <289@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes: > > I have a question for you A/UX gurus. On our A/UX system all the mail >files have too many permissions: i.e.: > >-rw-rw---- gus >-rw-rw---- harry > >We'd rather have the files be -rw-------, i.e. only accessible by the owner. > >Don't suggest chmod 600 *, as the mail file gets deleted when you read all >your mail; when recreated it gets -rw-rw----- mode again. BEWARE! I'd be almost certain that the group to which the files belong is the mail group -- a group to which no user should be allowed to change, and into which no user should be logging in. Mail delivery programs tend to be set-group-ID mail in order that they can manipulate mailboxes. If you make the mailboxes accessible only to the owner, it's almost certain that the mail delivery programs will no longer be able to put mail into the mailboxes. Security which prevents mail deliveries is likely to be regarded as counter-productive! To put it another way, having group access permissions is not automatically bad. They may actually indicate that a security mechanism is in operation -- as it is in this case. Having 600 permissions only, and having mail delivery programs set-uid root might appear to be an alternative. It's not. Delivery agents are (hopefully) written carefully so that the much safer set-gid procedure is sufficient to their needs. Making them set-uid root instead will not stop them from working, but it will open the door for certain types of attack on your system -- attacks which are not possible through a set-gid program. If Apple has found it necessary to make delivery agents set-uid root in order to get them to work, then slapped wrists are in order: they should be set-gid. (I don't yet have A/UX to play with, but I'm getting there.) Sadly, I have seen a number of system suppliers fall into this trap in tha past. That said, here's a recipe I used a while back on a slightly brain-damaged system where mail-boxes were inclined to be created with some permissions for ``others''. Assuming A/UX has a mailx command like that distributed with UNIX V.2 and later by AT&T, this is what you do: 1. Arrange that the default user interface to mail (as opposed to the mailer, which is another story) is the mailx program. If everybody uses Bourne or Korn shells, the most effective way to do this is to put mail () { mailx "$@" } or similar somewhere near the end of /etc/profile. If some or all users use cshells, then alias mail mailx in each affected user's .login should do the trick (unless A/UX' csh has a global cshrc under /etc which is read by any login cshell -- whether the user has their own .cshrc or not. Implementations vary -- check your documentation.) If you're ahead of me already, you will have noticed that either approach affects only the login shell, so users typing mail at a sub-shell get the original mail command. This can be a problem. It's easily solved for cshell users by putting the alias command in .cshrc, rather than .login; it can be solved for ksh users by setting up the ENV variable to point at a start-up file (see your documentation again); it can't be solved cleanly for Bourne shell users. DO NOT be tempted to rename mailx to mail, and then either install it where it's ahead of the original mail command on users' search paths, or rename the original mail to something like oldmail. This strategy will almost certainly break any mail delivery system which relies on using the mail command as a delivery agent. (Mailx, to give one example, has /bin/mail as its default delivery agent in all the implementations I've met.) 2. In the global set-up file for mailx (usually called something like /usr/lib/mailx/mailx.rc, but check your documentation) put the command set keep This arranges that mailboxes are truncated to zero length when empty, rather than being deleted. 3. Make sure that each user has a mail box, and that they own it. One way to achieve this is to send junk mail to everybody in the password file by using something like mail `cut -d: -f1 /etc/password` << E_O_F Rest easy in your bed tonight! I have made your mailbox more secure. George E_O_F Don't do this if your password file is under the control of Yellow Pages, as it may well have entries for remote users, and the mail system may forward annoying and irrelevant messages to remote mailboxes. (Mail may also barf when it sees user names beginning +, as they may in a YP password file.) Instead, work out who is local and send mail only to them. 4. In order to make sure that everything is buttoned down, as root, run chown bin /usr/mail chgrp mail /usr/mail/* chgrp mail /usr/mail chmod 660 /usr/mail/* chmod 770 /usr/mail (There's an outside chance the mailboxes may be in /usr/spool/mail. Yet again, check your documentation.) 5. Review your procedure for adding new users so as to ensure that an empty mailbox with the correct ownership, group and permissions is set up as part of the process. There it is. But you almost certainly don't need it. -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
dlnash@ut-emx.UUCP (Donald L. Nash) (02/03/89)
In article <981@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: > In article <289@berlin.acss.umn.edu> grg@berlin.acss.umn.edu > (George Gonzalez) writes: > > > > I have a question for you A/UX gurus. On our A/UX system all the mail > >files have too many permissions: i.e.: > > > >-rw-rw---- gus > >-rw-rw---- harry > > > >We'd rather have the files be -rw-------, i.e. only accessible by the owner. > > > >Don't suggest chmod 600 *, as the mail file gets deleted when you read all > >your mail; when recreated it gets -rw-rw----- mode again. > > BEWARE! I'd be almost certain that the group to which the files belong is > the mail group -- a group to which no user should be allowed to change, and Dominic goes on to describe how the mail stuff should all be in the group mail and that the executables should be set-gid. Well, I checked out how things are done under A/UX and it is wrong. /bin/mail is set-Uid root, /usr/mail is in group bin, and /usr/lib/mailx/rmmail is set-Gid bin. What follows are two shell scripts, one to make things like they should be and one to put them back the way they were. When these changes are made, the mail files in /usr/mail have permissions of -rw-rw---- and are in the group mail. All of the executables which manipulate the mail files are set-gid mail. I have tested this arrangement and it worked for me. I made sure that I was not root when I made the tests. Donald L. Nash The University of Texas System SMTP: dlnash@emx.utexas.edu Office of Telecommunication Services UUCP: ...!emx!dlnash ------------------------------cut here------------------------------ # # The following changes should be made to the mail subsystem to fix a # security hole: # chgrp mail /bin/mail # was in group root chmod 2755 /bin/mail # was 4755 chgrp mail /usr/mail # was in group bin chgrp mail /usr/lib/mailx/rmmail # was in group bin ------------------------------cut here------------------------------ # # The following changes were made to the mail subsystem to fix a security # hole: # # chgrp mail /bin/mail # was in group root # chmod 2755 /bin/mail # was 4755 # chgrp mail /usr/mail # was in group bin # chgrp mail /usr/lib/mailx/rmmail # was in group bin # # The following script will return things to what they were before: # chgrp root /bin/mail chmod 4755 /bin/mail chgrp bin /usr/mail chgrp bin /usr/lib/mailx/rmmail ---------------------------------end--------------------------------
antonio@Apple.COM (Antonio Ordonez) (02/04/89)
In article <10131@ut-emx.UUCP> dlnash@ut-emx.UUCP (Donald L. Nash) writes: >In article <981@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: >> In article <289@berlin.acss.umn.edu> grg@berlin.acss.umn.edu >> (George Gonzalez) writes: >> > >> > I have a question for you A/UX gurus. On our A/UX system all the mail >> >files have too many permissions: i.e.: >> > >> >-rw-rw---- gus >> >-rw-rw---- harry >> > >> >We'd rather have the files be -rw-------, i.e. only accessible by the owner. >> > >> >Don't suggest chmod 600 *, as the mail file gets deleted when you read all >> >your mail; when recreated it gets -rw-rw----- mode again. Since I posted a comment about confirming this and passing it on to engineering to be fixed I have been getting mail from people that say "It's not broken, don't fix it", because of that here is a follow-up The problem is that when a user has the mailbox file created, it gets created with the user as the owner of the file, but the group is the group of the sender (not mail or daemon), For example If the user guest that belongs to group x gets mail from a user belonging to group y, his mailbox file (/usr/mail/guest ) will have a group y. -rw-rw---- guest y Hope this clears the confusion if any was created. ---------------------------------------------------------------------------- #include <disclaimer.h> /* I'll think of a better one later */ Antonio Ordonez amdahl \ Technical Communications/Direct Response Center pyramid!sun - apple!antonio Apple Computer, Inc. (408) 996-1010 decwrl / ----------------------------------------------------------------------------