Two classes of login accounts are found under Trusted IRIX/CMW: user accounts and administrative accounts. The administrative accounts are sso (the Site Security Officer), ops (the Operator), root (the Superuser), dbadmin (the System Administrator), and auditor (the Auditor). All other accounts are ordinary user accounts. This chapter discusses the appropriate use and management of user and administrative accounts.
User accounts are at once the first line of defense of a trusted system and potentially the weakest link in that system. Every user account can break system security if it is not managed well, and every user account can be used to enforce system security. The way your user accounts are managed is crucial to a successful secure system.
Users must have ready access to the files and resources they need to perform their work. If this access is not available or is inconvenient, users circumvent the security policies and create threats to system security. However, users should also not be allowed access to unnecessary files and resources, as this is a security threat in itself.
Guidelines for effective secure management of user accounts are explained in this chapter. Procedures for administering user accounts and user groups are also presented.
The following sections give guidelines and instructions for creating user accounts.
Guidelines for user accounts are listed below:
Always use a different account name and user ID number for each user on your system. Each account should represent only one person, for accountability.
Never assign a login name that begins with a number. Some networks do not interpret these login names correctly.
Always choose unique user identification names for your users. For example, the login name steveb is a better choice than user001. A login name and the other information associated with an account should always be readily associated with the person who owns that account. It is generally possible to find distinguishing personal characteristics to differentiate between two or more users with similar names.
Include the user's full name and some personal identification, such as job title and phone number, in the comment field of the /etc/passwd file. Be careful, however, not to include classified information in the /etc/passwd file.
When you create user accounts, be certain that the user's environment is properly initialized for security. For example, in the .profile or .cshrc files, set the user's UMASK to 077. This initializes the default DAC permissions to allow only the user to access files he or she creates.
In the .profile or .cshrc files, set the PATH environment variable to include only those directories that the user is allowed to access. Also, in the PATH variable, make certain that the user's home directory is searched last, after the system directories, for commands. This guards against some forms of Trojan Horse attack. Do not include any temporary or public directories in the PATH, such as /tmp.
If possible, place a copy of the security policy in each account.
When you remove a user account, first make a backup tape of all files in the home directory belonging to that account.
When you remove a user account, assign new owners to any files on the system still owned by the removed user.
This section gives directions on creating user accounts. Choose the user's login name, user ID number, allowable security labels (or label ranges), and any administrative roles before beginning the process.
On a trusted system shadow passwords (/etc/shadow) are always used, see pwconv(1). When capabilities are installed, each user who is allowed to acquire capabilities on
demand must have an entry in the /etc/capability file. When MAC is installed, every user must have an entry in /etc/clearance. All of these databases, except /etc/passwd, are protected from perusal by non-privileged users.
It is important to follow the procedures exactly as they are specified in this guide. These procedures often involve manipulating sensitive system access files. Failure to follow the exact procedures listed here could leave your system without the designed security protections.
When you are using the No Superuser capability style, you must assign at least one user each of the system roles. When you are using the augmented Superuser capability style you should assign users to the system roles. When you are using the traditional Superuser capability style you may assign users to the system roles. The Superuser is responsible for everything, and is all powerful within the bounds of the system. When you are using the No Superuser capability style, this level of privilege does not exist.
The Site Security Officer is responsible for the enforcement of the system security policy. The Site Security Officer has UID 0, comparable to root. The Site Security Officer is allowed to
add entries to the user clearance and capability databases
change labels on files
set capability sets on executable files
shut down the system
view and manipulate audit trail files
enable and disable auditing of specific events
kill any process
restore backups
A permitted sub-role of the Site Security Officer is the Auditor. The Auditor is responsible for the audit trail only. The Auditor is allowed to
view and manipulate audit trail files
enable and disable auditing of specific events
kill any process
The System Administrator is responsible for all aspects of the system configuration except those related to the system security policy. For example, the System Administrator cannot add a user to the system without the help of the Site Security Officer, who is empowered to grant clearances. The System Administrator is allowed to
add entries to any system database except the user clearance and capability databases
manage the network configuration
The Operator is responsible for daily system maintenance activities. The Operator is allowed to
create backups
cancel print jobs
To summarize, the Site Security Officer sets security attributes, the Auditor watches what goes on, the System Administrator configures the system, and the Operator performs backups.
All non-security-related system administration should be done using the cadmin(1M) tools. These tools verify that the invoking user is allowed to perform the necessary role.
When MAC is installed, users who perform administrative roles must be cleared for the labels required by those roles. Site Security Officers must be cleared for the dbadmin label (to modify the clearance database) and msenhigh/mintlow (to restore or import files safely). Auditors must be cleared for dbadmin so they can look at the audit trail files. System Administrators must be cleared for dblow to modify the system configuration files. Operators must be cleared for msenhigh/mintlow to allow backups.
The System Administrator and the Site Security Officer must cooperate to create a new user account. The System Administrator's duties end where the system security state begins. The security-specific information must be supplied by the Site Security Officer. Thus, adding a user requires two steps:
The System Administrator creates a passwd file entry and a home directory for the user.
The Site Security Officer uses dbedit to create entries in the /etc/shadow, /etc/clearance, and /etc/capability files for the user and uses chlabel to set the MAC label on the user's home directory.
To create the /etc/passwd file entry, perform these steps:
Give the command:
dbedit /etc/passwd |
Add a line with the new user's information of the form:
username:*:UID:GID:Comments:home-dir:default-shell |
Here is an example line:
jeffz:*:1998:50:Sample User:/usr/people/jeffz:/bin/csh |
To create the user's home directory, perform these steps:
Change directories with the cd(1) command to /usr/people.
Give the mkdir(1) command to make a home directory for your new user. Name the directory with the same name as the new user.
Use the chown(1) and chgrp(1) commands to change the ownership of the new directory to the new user.
If your new user is using the C-shell (/bin/csh), copy the files /etc/stdcshrc and /etc/stdlogin to the new directory, naming them .cshrc and .login. Also, make sure that the user's lowest allowable login label is not dblow, since users at dblow cannot use the C-shell.
If your new user is using the Bourne shell (/bin/sh), copy the file /etc/stdprofile to the new directory, naming the file .profile.
To edit the /etc/clearance, /etc/capability, and /etc/shadow files, perform these steps:
Use dbedit to add an entry to the /etc/clearance file according to the format described below. The example shows /etc/clearance entries for a Superuser (sue), a Site Security Officer (samsord), an Auditor (audry), two System Administrators (andy and amy), and an Operator (oswald). Andy is also allowed to be an operator. All of these users do "real" work on the system except for Andy, who is a full-time System Administrator. Everyone but Andy is cleared for userlow, which is their default label:
sue:userlow:dblow dbadmin msenhigh/mintlow userlow samsord:userlow:dbadmin msenhigh/mintlow userlow audry:userlow:dbadmin userlow amy:userlow:dblow userlow andy:dblow:dblow msenhigh/mintlow userlow oswald:userlow:msenhigh/mintlow userlow |
Use dbedit to add an entry to the /etc/capability file according to the format described below. The following are /etc/capability entries for a number of users. Note that the dbadmin account has a master capability that includes all defined capabilities:
auditor:CAP_AUDIT_WRITE,CAP_AUDIT_CONTROL,CAP_KILL+eip dbadmin:all=:all= ernie:all=:CAP_FOWNER,CAP_SETFCAP+eip bert:CAP_FOWNER,CAP_ENGR, |
An /etc/capability file entry includes the account name and the capabilities associated with that account in a comma-separated list.
Use dbedit to add an entry to the /etc/shadow file according to the format described below. The following are /etc/shadow entries for two users:
root:kEXFeXFTPoxE bill:6k/7KCFRPNVXg,z/ |
An /etc/shadow file entry includes the user's account name and encrypted password, separated by a colon (:). When you add an entry, you need only add the account name and a colon the passwd utility encrypts and enters the password.
When changing the labels for the new user, follow these steps:
Give the chlabel(1M) command to change the label of the files in the directory to the lowest allowable label of the new user. You must use the lowest allowable label so the user can access those files without regard to his or her login label.
Give the chlabel(1M) command to change the label of the new directory to the lowest allowable label of the new user. You must use the lowest label or the user cannot find his or her home directory when logging in at the lowest label.
Additionally, the Site Security Officer should set a password for the new user, following these steps:
Give the commands:
passwd jeffz |
and
passwd -f jeffz |
The first command creates a password for jeffz. This password must be selected by the System Administrator and told to the new user. The second command forces the new user to change the password at the first login.
Invoke the userck(1M) utility to check that all procedures have been performed correctly. The utility warns you if any entries violate system standards. The verbose option to this utility is often useful. Use the command as follows:
userck -v |
When a user has finished all use of a secure system, that user's account should be closed quickly. It is primarily the Site Security Officer's concern that unauthorized users not be allowed on the system, so the Site Security Officer needs to be informed at once when a user leaves or ceases to use the system. The Site Security Officer should replace the former user's encrypted password field (in /etc/shadow) with the string "*INVALID*" and both capability lists in /etc/capability with the string "*INVALID*" and both clearance fields in /etc/clearance with the string "*INVALID*". The entries in the files should not be removed. The Site Security Officer should also check for crontabs, at jobs, or print jobs the former user may have queued.
Once the user is removed, check all system files and change ownership of any files on the system that are owned by the defunct user account. If the user had access to other accounts, change the passwords on those accounts immediately. Also, remove the user's name from all groups on the system.
The security clearance information assigned to a user may be changed by the Site Security Officer by updating the appropriate entry in the /etc/clearance file.
If the user's new security clearance includes all of his or her old labels, that user may remain logged on to the system and active while the clearance is updated.
On a trusted system, you typically have one or more confidential projects at any given time. Also typically, the users working on those projects need to share files and resources. To accommodate this need, you can create user groups. DAC provides a set of permissions for a file owner's group, as well as for the owner of the file and the whole user community.
Trusted IRIX/CMW provides for multiple concurrent groups. That is, a particular user can be a member of any number of groups, or even of all groups on your system. When you log in, your group ID is set to the group ID in your entry in the passwd file. To change to a different group, use the newgroup(1) command.
Group your users based on their common needs. Put all the users on a given project in the same group. All members of a group acquire the group ID in addition to their user ID when they log in. Using the DAC permissions and appropriately defined Mandatory Access Control (MAC) permissions, it is possible to give each member of a project team complete access to necessary files and exclude other users from confidential files.
Guidelines for user groups are:
Place users working on the same project or who have similar needs in a group. Consider, for example, a group of data entry clerks. Users with similar needs may work on different projects, but they all need similar tools and resources.
Add a group at the same time you add each new project to your system.
Assign each group a unique and readily identifiable group name. For example, motordev is a better name than group001.
Never begin a group name with a number, as this can be misinterpreted by the system.
The file /etc/group maintains a list of the valid groups and their members. It is possible to edit the /etc/passwd file and change the ID number of a given group. No checking is done between these two files, and the System Administrator must make certain that all user IDs and group IDs given in these files are correct.
Run the pwck program frequently to check your system for potential problems in the /etc/password file.
It is sometimes desirable to create a group containing only a single user who is performing specialized work.
To add a group, the System Administrator logs in at the label dblow and performs the following steps:
Give the command:
su dbadmin |
Give the command:
dbedit group |
Add a line for the new group in the form:
groupname:*:username,username,username |
Exit dbedit and the dbadmin account.
When a group has no more users, or a project group has finished all work, the group should be nullified. You should not, however, remove a group entirely, as the possibility exists that the same group name or ID number might be reused, creating a security hazard. To remove a group, use dbedit to edit the group file in the same way as to add a group, and remove all usernames from the entry for the defunct group. This way, the group is effectively removed, but the entry remains and so cannot be reused.
At your convenience, search through the system and find files that are owned by the defunct group and change their ownership to another group or remove them.
The amount of administration that can be done by a single individual is significantly influenced by the capability style chosen for a system. As a rule, the more you care about protecting your information, the less you want to have a single individual with complete control of the system.
When you use the Traditional Superuser style, the only way for a process to have privilege is for it to have an effective userid of 0, which corresponds to the username root or sso. All privileged processes have universal privilege, and must be trusted to use only those which are appropriate to the task at hand. The setuid mechanism can be used to grant an unprivileged user privilege by setting the effective userid.
In the Augmented Superuser style, a process can have privilege either because its effective userid is root or because it has one or more capabilities. Processes with a userid of root have universal privilege and must be trusted to use only those that are appropriate to the task at hand. Processes with a set of capabilities have limited privilege and need only be trusted to use those correctly. The setuid mechanism can be used in the traditional way, or a file capability set can be used to explicitly grant or deny privileges available to invocations of the program.
In the No Superuser style, a process can have privilege only when it has one or more capabilities. Processes with a userid of root or sso have no special privilege whatsoever. Processes have limited privilege and need only be trusted to use those correctly. The setuid mechanism can be used in the traditional way, but the effective userid of root is not considered sufficient to grant privilege. A file capability set can be used to explicitly grant or deny privileges available to invocations of the program.
The Superuser role is obviously dependent on which Superuser style you are using. In the Traditional style, the Superuser may, and in fact usually must, perform any system administration activity desired. In the Augmented style the Superuser may perform any system administration activity, but other processes performing other roles may exist as well. In the No Superuser style, the Superuser role is not used.
The root userid owns most of the system administrative data files. The root userid is associated with the System Administrator role. If you are using either of the Traditional or Augmented styles, the Superuser role can be thought of as a System Administrator role with extended powers. If you are using the No Superuser style, the Superuser role is replaced by the other, distinct roles.
The Site Security Officer (SSO) is responsible for maintaining the system security policy. This policy is defined by a set of system configuration database files:
| /etc/capability | user allowed capabilities | |
| /etc/clearance | user clearances | |
| /etc/mac_label | a directory containing the following files | |
| categorynames | names for sensitivity categories | |
| divisionnames | names for integrity divisions | |
| gradenames | names for integrity grades | |
| labelnames | short names for MAC labels | |
| lbldb_bin | hashed label names | |
| levelnames | names for sensitivity levels | |
| minttypenames | names for integrity label types | |
| msentypenames | names for sensitivity label types | |
| /etc/shadow | encrypted passwords |
| sso at Low Clearance (dblow) | | |
| sso at High Clearance (msenhigh/mintequal) | | |
| sso at various user labels (msentcsec) | |
The System Administrator (dbadmin) is responsible for maintaining the functional state of the system. This task includes, but it not limited to, maintaining these configuration database files:
| /etc/aliases | a configuration file for e-mail groups | |
| /etc/exports | a configuration file for directories exported via NFS | |
| /etc/fstab | a configuration file for filesystems mounted both locally and via NFS | |
| /etc/group | a configuration file for group name to group ID mapping | |
| /etc/hosts | a configuration file for system to Internet address mapping | |
| /etc/motd | the login message file | |
| /etc/networks | a configuration file for network to Internet address mapping | |
| /etc/passwd | a configuration file for user name to user ID mapping | |
| /etc/sendmail.cf |
| |
| /etc/sys_id | a file that holds the name of this system |
The Operator is responsible for day-to-day system state changes. This includes making backups and cancelling print jobs. The operator does not determine or maintain system policies.
The Auditor role is used to manage the System Audit Trail. At installation time, the Auditor is responsible for setting up the audit subsystem and seeing that it is activated on the system. Also, the nature and extent of auditing is controlled through the
sat_select(1M) command. The Auditor role is cleared at the dbadmin level. The dbadmin label is an alias to the label msenadmin/minthigh. In order for a user to use su(1) to become Auditor, the original login session must have been running at this label; hence, any user cleared to perform the Auditor role must also be cleared for the dbadmin label.
The Auditor role includes the ability to modify system audit parameters and to kill(1) any process on the system in response to events that might appear in the audit trail. Through Mandatory Access Control and Discretionary Access Control, the Auditor is allowed to access files that no other user is allowed to change, but MAC and DAC also prevent the Auditor from accessing any user files.
Once the system is set up, the auditor is responsible for storing the audit files and periodically viewing and editing the files to produce a record of the system usage. A number of tools are available for use with the system audit trail. Among these are:
sat_select(1M)
sat_echo(1M)
sat_interpret(1M)
sat_reduce(1M)
sat_summarize(1M)
satctl(2)
satread(2)
satwrite(2)
sat_eventtostr(3)
Each tool is fully described in its own reference page.
Using these tools, the auditor creates records of all system activity. It is also the job of the auditor to review the audit logs periodically to check for security violations or notable activity. Some types of activities to be flagged for observation are:
Attempts at unauthorized entry
System usage at unusual hours or from unusual locations
Attempts at access control violations
Unexpected use of privilege
Connections with systems outside of the local network
Any activity by particularly interesting subjects
Any accesses of particularly interesting objects
Modifications of system data files
Manipulation of the audit trail itself
Any notable instances of user behavior discovered by the auditor should be immediately brought to the attention of the Site Security Officer.
For a complete discussion of auditing under Trusted IRIX/CMW, please refer to the guide titled IRIX Admin: Backup, Security, and Accounting.