A/UX Mail files

[Dominic Dunlop]

In article <289 at berlin.acss.umn.edu> grg at 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 at sphinx.co.uk  domo at riddle.uucp