UNIX
This chapter covers security issues related to post.office and your E-mail system:
- run-time permissions
- directory and program owners
- mail account security
UNIX |
This chapter covers security issues related to post.office and your E-mail system:
|
POST.OFFICE SECURITY (UNIX PLATFORM) |
This chapter brings together different issues pertinent to security. The subject is broken down into two areas: system security, and mail account security. Most of the issues discussed here are also mentioned elsewhere in the manual.
System security is concerned with the protection of the computer system on which post.office is operating. This includes services on the machine which are unrelated to post.office as well as the configuration information which is required for post.office operation.
Mail account security relates to the protection of the information in the post.office databases which is relevant to the user's and Postmaster's mail accounts.
Message security concerns the protection of user and system E-mail from unintentional eavesdropping and or interception. The current version of post.office does not offer any form of message encryption.
The post.office approach to system security is to carefully isolate post.office from the remainder of the system. A special group and user are created for that purpose.
During the installation of post.office a special account (we suggest calling it the MTA account) and group (also MTA) are established on the machine for the mail system to operate under. The account's permissions are intentionally limited to only those necessary to operate post.office.
The majority of executable modules which comprise post.office are designed to operate in this intentionally limited environment. The few instances in which post.office modules are allowed to operate with more liberal permission are required by the design of UNIX systems.
The MTA account (and group) permissions provide a significant share of the system security afforded by post.office.
With one exception (discussed below) the daemon portion of post.office is the only module allowed to use root permissions during run-time. The majority of the executable code which comprises post.office is run under the MTA user account and group and cannot gain access to the host system beyond what is required for the mail system.
The post.office daemon, known as the dispatcher, is the module which controls the overall operation of the mail system as well as permissions for the other post.office modules. As the dispatcher's main role in post.office is the management of the tasks necessary for the mail delivery it does not actually communicate with any users or other machines.
The dispatcher initially runs with the root (or super-user) permissions when post.office is started in order to can carry out initialization of the network connections. Immediately following necessary initialization, and prior to accepting or processing any messages, the dispatcher irrevocably releases the root permission and hence takes only the permissions set up for the post.office system during installation.
Thus, all special privileges are dropped and only the MTA users privileges are retained during normal operation. All other (with the exception below) network and local post.office modules are run by the dispatcher with these limited permissions.
Note: There is one to the rule of limited permissions: a utility module which works with UNIX-Deliver to create a mail drop file. Due to the ownership requirements of the UNIX mail drop file (the owner is the person who is receiving the incoming mail and the group is usually the mail group) it is necessary for there to be a special program which is able to create an empty file with the proper permissions allowing access for both the mail system (to deposit mail) and the user (to pick up mail from the file). This module (owner is root) runs with the set user id bit set in its permissions which allows it to assume the permission for the root account. The source code for this module is available for inspection and modification upon request.
There are three directory trees which post.office uses in normal operation: the executable, post.office, and mailbox directories. The permissions for each of these directory trees are designed to allow proper operation of the post.office modules while providing a secure envelope for the host system running post.office.
The owner and group on these directories are as follows:
| Directory Tree | Owner | Group |
|---|---|---|
| executables | root | MTA |
| post.office | MTA | MTA |
| mailbox | MTA | MTA |
This section describes various post.office features which are used to protect the configuration of your account database (by controlling carefully the issuing and processing of remote configuration forms) as well as to protect the delivery of E-mail to users with post.office accounts.
Fields on the account form which are relevant to account security are illustrated in the two examples below. Fields discussed are: Mail-Account-Password, Access-Domains, Internet-Addresses, and the delivery fields. Fields not related to our discussion have been omitted for the sake of clarity (with the exception of the Account Name field which was included so we can keep a handle on things).
These hypothetical accounts will be used throughout the section to demonstrate how the security features of the post.office Managers work.
===== GENERAL ACCOUNT INFORMATION =========================================
User's-Real-Name: [Jane Doe]
Mail-Account-Password: [Sur+Fer!]
Access-Domains: [chicago.software.com]
[199.17.234.0]
----- E-MAIL ADDRESSING INFORMATION -- INTERNET (SMTP Channel) ------------
Internet-Addresses: [Jane.Doe@Software.com]
[jane.doe@chicago.software.com]
[jane@software.com]
[doej@software.com]
----- LOCAL DELIVERY INFORMATION ------------------------------------------
POP3-Delivery: [POP]
POP-Login-Name: [JDoe]
Forwarding-Addresses: [Bill.Zoom@Software.com]
----- ACCOUNT SECURITY PARAMETERS -- ** Optional ** -----------------------
Access-Domains: [chicago.software.com]
[199.17.234.0]
|
Figure 8.2a: These selections from Jane Doe's account form show the fields which are relevant to our discussion on security.
===== GENERAL ACCOUNT INFORMATION =========================================
User's-Real-Name: [Support Account]
Mail-Account-Password: [Friendly'nCourteous*##!!]
----- E-MAIL ADDRESSING INFORMATION -- INTERNET (SMTP Channel) ------------
Internet-Addresses: [Support@Software.com]
----- LOCAL DELIVERY INFORMATION ------------------------------------------
Forwarding-Addresses: [jane.doe@software.com]
[]
----- ACCOUNT SECURITY PARAMETERS -- ** Optional ** -----------------------
Access-Domains: [chicago.software.com]
[199.17.234.0]
|
Figure 8.2b: These fields, taken from the "support@software.com" account form, are those fields which are relevant to the post.office security features discussed forthwith.
The WWW-Server will answer web (WWW) client queries on the port number assigned during the installation (typically port 80 or 81). Upon connection to the post.office WWW-Server, there is a three step authentication procedure enforced on all initial web requests:
The calling web client's IP address is checked against the global web access domain list (this is on the system security form under the Limit-WWW-configuration-from: field). If the list is empty, or the list contains a specific or wildcard match for the client's address, the WWW-Server issues the Authentication Form to the client. If the list is not empty and the web client does not match any of the entries, the WWW-Server responds with an error and the connection is immediately terminated.
The authentication form prompts the user to enter their E-mail address and appropriate password. The password is not echoed on the users screen. After the user has entered both fields and selected the "Submit Authentication" button, the form information is delivered to the WWW-Server for verification.
If the E-mail address matches an existing account's E-mail address, the account's access domains entry is check to verify that access is allowed from the web client's IP number. If the account's access domains entries preclude the web client's IP number, a message will be returned to the web client explaining this.
If the web client's IP address is allowed, the submitted password is checked against the account's password. If the passwords do not match, an access denied message is returned to the WWW client. If the passwords do match, the WWW-Server creates an access token for the session and returns this along with a web form (a user will get their account information form, and a postmaster will get a list of available form).
Currently the authentication information is sent to the WWW-Server in an unencrypted form and may be monitored if there is physical access to your network by others or your web session is over a public network.
Access tokens are created with a time stamp and the web client IP address. The tokens are encoded into all further communications with the web client (in the URL). The token's time stamp is used to limit the time period for which an issued token is valid. The time limit is under the postmaster's control (the time period set using the system security form) with a default of 5 minutes. The token time stamp is reset with each form request or form submission so there is no time limit on a web session, only on the time between form request/submissions. In addition, the token is only valid for the web client's IP address and cannot be transferred to another machine (to switch to a different machine the user must re-submit an authentication form from the other machine).
The safeguards which relate to remote configuration of forms and to form request are account determination, access domains, and passwords (passwords are not used for a form request, only in the forms themselves). These safeguards apply to issuing and processing forms such as the account form and the information forms.
post.office makes a determination of who is requesting or sending in a form by looking at the "From:" header line on the envelope of the mail message which contains the form (or request).
This address is compared to the addresses in the account database. For example, post.office may receive a form request in the envelope below:
To: <Accounts@software.com> From: <Jane.Doe@software.com> ------------------------------------------------------------------------------- To: Accounts From: Jane.Doe@software.com Subject: I want some information forms ------------------------------------------------------------------------------- Info <Jane.Doe@software.com> Info <Support@software.com>
|
Figure 8.2.1a: A typical mail message containing a form request from Jane Doe. The first two lines make up the electronic envelope which contains the message. The balance of the illustration contains the message itself: the headers followed by the body. Note that post.office makes its account determination based on the information contained in the envelope (bold), not the message headers.
post.office compares the address "Jane.Doe@software.com" (on the envelope) to the SMTP addresses in its account database. This address in this database may be associated either with the Internet-Addresses field (as is the case in figure 8.2a) or with the Forwarding-Addresses field (as in figure 8.2b). In this manner, post.office ascertains that Jane Doe has access to two accounts: her own (as Jane.Doe@software.com is an Internet-Address for her account) and the support account (as Jane.Doe@software.com is in the Forwarding-Addresses list for the support account). Since she is not postmaster, the only form to which she has access is the information form which she is requesting.
Had post.office's search revealed that Jane was also listed in the Delivery field of the postmaster account, she would then also have access to that account, and, as a result, to the whole post.office system and any other form she might want.
Note: Jane has listed in the Forwarding-Addresses field of her account, the address Bill.Zoom@Software.Com. This means that Bill winds up getting any messages which are sent to support (through Jane and then on to Bill). However Bill, whose address is not listed in any field of the support account, has no access to the information for that account.
Once account determination has been carried out, post.office then consults access domains to verify that Jane is allowed to do what she wants to do from where she is doing it.
User's-Real-Name: [Jane Doe]
Access-Domains: [chicago.software.com]
[199.17.234.0]
|
Figure 8.2.1b: Jane Doe's access domain, taken from her account form (see 8.2a, above).
Once post.office has determined who is sending a form or a form request (we continue with the example from the previous section of Jane, who is requesting some information forms), post.office verifies that the domain portion of the From: address (software.com, highlighted above in figure 8.2.1a) listed on the envelope of the message is within the correct access domain list for the account (figure 8.2.1b above).
post.office compares this address to Jane's access domain. If the address includes the phrase software.com or is located on a host with a 199.17.234.0 IP address ("0" acts as a wildcard), the request is approved, and Jane will get the information form for her accounts.
Note: The form is delivered to Jane's account, not to the address on the form request. Thus, if Jane uses POP delivery for her account, she will still have to retrieve the message from the post.office host and provide her password -- yet another security hurdle.
In this case she will get two forms: one for her personal account and one for the support account, as per the account determination discussed above and in line with her request.
When forms are submitted there is one additional step: password verification.
Note: A domain literal (used in the Access domains list - i.e. 199.17.234.0) is more secure than a domain name (such as "software.com"), so if it is the same to you, stick to the numbers, particularly with key accounts such as the postmaster account.
However in some cases (when there is no DNS server or host file entry), domain literals are not allowed by the managers as the envelope from address on a form request or a form submission (i.e. if Jane sent mail as Jane.Doe@[199.17.234.2] - the manager would reject the mail even if 199.17.234.2 was within software.com).
Once Jane submits her information form, having made the changes she wanted, post.office compares the password on the form to the password stored in the account database and verifies that it is an exact match (recall that post.office has already made an account determination as well as verified the access domain). If the password is O.K. post.office processes the form.
Every mail account in post.office has a password which is initially set up by the administrator and is under the control of the account user. A one-way encryption (MD5) is applied to the password when it is stored in the account database to insure secrecy. This password is used to control access to both the account's mail (in the case of a remote delivery like POP3) and to account information (via the account information form).
Passwords are arbitrarily long strings of characters (6 characters minimum), their length limited only by your patience and the fact that they must be confined to a single line on a form. post.office passwords are case senSiTive.
In addition to being a normal account which receives incoming messages, the postmaster account (through its password) plays a crucial role in controlling the message transport system configuration and account information. The postmaster password is the primary security filter for the administration of the message system and it should be appropriately protected.
The Postmaster can "Lock" post.office mail accounts to prevent access to the account information and prevent delivery of mail via POP. This is accomplished by requesting the account form for the appropriate account and placing the word "Lock" in the Account's-Password field.
When an account is locked the prior password remains with the account but all access requiring a password for the account is denied until the lock is removed by the postmaster. A lock on an account is removed simply by putting either the word "Unlock" in the Account's-Password field (and the previous password is operational) or by typing a new password in the field (the account is unlocked and the password is changed).
How post.office protects user messages and the POP mailbox.
When a user selects POP3 delivery, messages are stored in a subdirectory of the mailbox (which is chosen during installation). The owner and group of the mailbox directory are given only MTA permissions to secure access from individuals or programs on the system running post.office.
Access to messages via POP3 is controlled by the Access-Domain and Account-Password fields.
For example, when Jane Doe checks her mail, she must do so from a host whose address includes either the phrase "software.com" or "199.17.234.0" (where "0" is a wildcard). Unless she meets this condition and enters the correct password for her account, access to her messages will be denied.
Note: Users should be wary of using their passwords on public networks such as the Internet. Eavesdropping is fairly easy, and amazingly enough there are people who are bored enough to think your mail may be interesting enough to warrant the effort of snooping out your password. The best bet is to keep your access domain limited to within your organization which you should protect via your network routing set-up or your firewall. That way, you operate completely within a secure network which protects you from the evil lurking beyond your kingdom walls.