Enforcing Security Requirements

To ensure that the security of the system is not compromised, administrators need to protect passwords, files and audit data and to train computer users to do their part. To be consistent with the requirements for an evaluated configuration, follow the guidelines in this section.

Training Users About Security Requirements

Each site's security administrator ensures users are trained. The security administrator should hand off the following rules to new employees and remind existing employees of these rules from time to time.

Your organization may wish to provide additional suggestions beyond those listed below.

Users' Security Rules

Anyone who knows your password can access the same information that you can without being identified and therefore without being accountable.

Do not tell anyone else the password.

Do not write the password down or include it in an email message.

Choose passwords that are hard to guess.

Do not leave your computer unattended without locking the screen or logging off.

Be aware that sender information in email can be forged.

Remember that administrators do not rely on email to send instructions to users. Do not ever follow instructions from administrators in an email without first double-checking with the administrator.

Do not send your password to anyone by email.

Because you are responsible for the access permissions on files and directories that you create, make sure that the permissions on your files and directories do not allow unauthorized users to read or change a file or list the contents of or write into a directory.

Using Email

It is poor practice to use email to instruct users to take an action.

Tell users not to trust email with instructions that purport to come from an administrator. This prevents the possibility that spoofed email messages could be used to fool users into changing a password to a certain value or divulging the password, which could subsequently be used to log in and compromise the system.

Enforcing Password Requirements

The System Administrator role is responsible for specifying the original password for each account and for handing off the passwords to new accounts. The System Administrator role must specify a unique user name and a unique user ID when creating a new account. When choosing the name and ID for a new account, the administrator must ensure that both the user name and associated UID are not duplicated anywhere on the network and have not been previously used.

Security Administrator Password Administration Rules

Make sure that the accounts for users who are able to assume the Security Administrator role are configured so that the account cannot be locked. This ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if it ever happens that all other accounts are locked.

Hand over the password to an account in such a way that the password cannot be eavesdropped by anyone else.

Change an account's password if there is any suspicion that the password has been discovered by anyone who should not know it.

Never reuse user names or UIDs over the lifetime of the system.

Ensuring that user names and UIDs are not reused prevents possible confusion over:

• Which actions were performed by which user when audit records are analyzed

• Which user owns which files when archived files are restored

Changing Root's Password

The Security Administrator role can change any account's password at any time except for the password of the root role. Because root's UID 0 is below 100, the SMC considers root to be a "system account," and the SMC does not allow any changes to be made to system accounts. If root's password needs to be changed, root must make the change using the TP menu Change Password option.

Protecting Information

Administrators are responsible for correctly setting up and maintaining DAC and MAC protections for security-critical files, such as the shadow(4) file containing encrypted passwords, the local prof_attr(4), exec_attr(4), and user_attr(4) databases, and the audit trail.

Because the protection mechanisms for NIS maps and NIS+ tables are not subject to the access control policy enforced by the Trusted Solaris software, the default NIS maps and NIS+ tables should not be extended, and their access rules should not be modified.

Protecting Passwords

In local files, passwords are protected from viewing by DAC and from modifications by both DAC and MAC. Passwords for local accounts are maintained in the shadow(4) file that is readable only by root: The Security Administrator role should ensure that the /etc/shadow file is protected by MAC at ADMIN_LOW, and by DAC by root (owner), sys (group), and 400.

trusted4% ls -l /etc/shadow; getlabel /etc/shadow
-r--------   1 root     sys          307 Sep 7  2001 /etc/shadow
/etc/shadow:    [ADMIN_LOW]

The password field in the NIS+ passwd.org_dir table is protected by NIS+ restrictions on access to fields within tables. When any user or administrator tries to view the passwd.org_dir table, the only encrypted password that displays is the one belonging to the account.

The following example shows that while user ashish's password field shows as *NP* when the user roseanne invoked the niscat(1) command, barbar can see the encrypted password for her own account.

trusted5% whoami
roseanne
trusted6% niscat passwd.org_dir
. . .
ashish:*NP*:33333:10:Ash Ish:/home/ashish:/bin/csh:*NP*
barbar:0dk1EW44:10:Bar Bara:/home/barbara:/bin/csh:38442::::::

There is no shadow.org_dir table.

With NIS, configure the shadow database as a secure map. Secure maps are only readable from a privileged port, thus only a privileged program could access the encrypted password. Sites that need more security than NIS provides should use NIS+.

Administering Groups

The admin needs to verify on the local system and on the network that all groups have a unique group ID (GID).

When a local group is deleted from the system, the administrator role must ensure the following:

• All objects with the GID of the deleted group must be deleted or assigned to another group.

• All users who have the deleted group as their primary group must be reassigned to another primary group.

Deleting Users

When an account is deleted from the system, the administrator and Security Administrator must take the following actions:

• The account's home directory must be deleted.

• Any processes or jobs belonging to the deleted account must be removed:

  • Any objects owned by the account must be deleted or the ownership must be assigned to another user.

  • Any at or batch jobs scheduled on behalf of the user must be deleted. See the at(1) and crontab(1) man pages, if needed.

• The user (account) name and UID must be retired and not reused.