Permissions and Privileges

The purpose of this assignment is to add proper security features to the mailer.

• You will be given a script to take all of the mailbox names and add them as users to your system
• All mailboxes must be owned by the proper user
• You can decide on the proper permissions; however, no user should be able to read or write any other users' mailboxes or mail except that they may send them mail
• mail-out must  be a privileged program in order to be able to deliver mail. You may use message-passing, setuid, or setgid, as you choose
• You may, if you wish, make mail-in privileged, but that is not required and (for some designs) not necessary
• Your system must be secure

Grading for this assignment is based on general functionality, not security under attack. Is mail delivered properly? Do all mailboxes and mail messages have the proper permissions? Have you adequately documented any special instructions, e.g., firing up a daemon?

You may use setuid, setgid, ACLs, message-passing, or any other suitable mechanisms.

Because the mailboxes—which are directories—have to be owned by the receiving user, you may have to use the sudo and chown commands to give them away. Your tree-creating script would thus be two scripts: one to create all of these mailboxes, and one, invoked via sudo, to issue the chown commands. (As a consequence, you will generally need to use sudo to delete a tree.)

To simplify testing, create a mailbox for your own userid, too. That way, you'll be able to verify that the authorized user can read their own mail but not anyone else's.

There are several possible ways to handle mailbox protection. One is to make each mailbox owned by the recipient and not readable, etc., by others. To write a message to such a mailbox, mail-out must use root privileges—but how? One way is to create the files as root and then use chown to give them away. An alternative is to use root privileges to become that user, and then create the file.

A second alternative is to use group permissions: make sure that the mailboxes are writable by some group (which you can create with the addgroup command). The mail-out command could then be setgid to that group.  Think carefully about the permissions the mailboxes and the created files should have!

A third alternative is to use ACLs, to grant permissions more easily. It is possible for even a non-superuser to create an ACL granting access rights to another user. See https://linux.die.net/man/5/acl and the man pages it links to, especially https://linux.die.net/man/3/acl_set_file. (Note: ACLs are conceptually simple; the library routines are not.) Again, think through file ownership and permissions.

Are there other choices? Probably!

You may, if you wish, create other programs to help implement your security solution.

The goal is security. Your design must satisfy the following properties:

• Only the intended recipient should be able to read email sent to them
• Only that person should be able to overwrite such message
• Only that person should be able to see how many are pending for them
• Although there is no ``delete'' operation in the program, your security solution must prevent anyone else from deleting email files belonging to anyone else, or in any other way causing them to lose messages that have been sent
• If mail-out (or any other helper program you create) will assume error-free input because of how it is nominally invoked, you must ensure that no one else can invoke it for their own reasons. Alternatively, these programs can do their own error-checking. For example: mail-in is supposed to format messages properly. If mail-out assumes proper formatting, your must configure things so that only mail-in can invoke it.
• It must not possible for anyone to abuse mail-in or mail-out to gain any extra privileges.
• If there are any special instructions, e.g., to fire up a daemon for a message-passing solution, you must document that in a README file. However, you are not obligated to document your design or security assumptions—those are for the attacker to find…
• Your Makefile and README file must make it simple to install your code and set up your tree with the proper ownership and permissions. You can use make variables for the location of the tree in whose bin directory things should be installed, via make TREE=dest-tree install. This target should copy all necessary executables to the proper place, including tree setup scripts. The tree setup scripts should not install your test data; that's for your attacker. However, when you submit HW4, you should include test scripts, to make life easier for the graders.

Again, grading for this assignment is based on simple functionality; the TAs will not otherwise assess your code for functionality. But watch out for hw5…

NOTE WELL: Because your assignments are inputs for other students' work on the next assignment, there is an extra penalty associated with late submission of this assignment. See the next assignment for details.