Two classes of login accounts are found under IRIX using the Commercial Security Pak: 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 account administrators 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.
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 the user to access only those 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, 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. 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, and is allowed to:
add entries to the user clearance and capability databases
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, and 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 capability database
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 System Manager tools. These tools verify that the invoking user is allowed to perform the necessary role.
The System Administrator creates all new user accounts using the System Manager. Additionally, you should set a password for the new user as follows. Give these commands:
passwd username passwd -f username |
The first command creates a password for username. 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.
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*.” 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.
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.
IRIX 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, it is possible to give each member of a project team complete access to necessary files and exclude other users from confidential files.
Suggested 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.
If you are creating new user accounts and a specialized group for those users, be sure to create the group entry before allowing any of the users to log in.
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 the System Manager to edit the /etc/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 user ID of 0, which corresponds to the user name 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 user ID.
In the Augmented Superuser style, a process can have privilege either because its effective user ID is root or because it has one or more capabilities. Processes with a user ID 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 user ID 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 user ID 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 user ID owns most of the system administrative data files. The root user ID 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 capabilities. | |
| /etc/shadow | Encrypted passwords. | |
| Kerberos Files | All Kerberos-related files. |
The System Administrator (dbadmin) is responsible for maintaining the functional state of the system. This task includes, but it not limited to, maintaining these files:
| /etc/aliases | A configuration file for e-mail groups. | |
| /etc/exports | A configuration file for directories exported through NFS. | |
| /etc/fstab | A configuration file for filesystems mounted both locally and through 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 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 Discretionary Access Control, the Auditor is allowed to access files that no other user is allowed to change, but DAC also prevents the Auditor from accessing any user files not normally accessible.
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, including these:
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. These are the types of activities to be flagged for observation:
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 IRIX, please refer to the guide titled IRIX Admin: Backup, Security, and Accounting.