Go to main content

Oracle® Solaris 11.3 Security and Hardening Guidelines

Exit Print View

Updated: March 2018
 
 

Security Requirements Enforcement

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

Users and Security Requirements

    Each site's security administrator ensures that users are trained in security procedures. The security administrator needs to communicate the following rules to new employees and remind existing employees of these rules on a regular basis:

  • Do not tell anyone your password.

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

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

  • Choose passwords that are hard to guess.

  • Do not send your password to anyone by email.

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

  • Do not leave your laptop or other mobile devices unattended in an insecure location.

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

    Be aware that sender information in email can be forged.

  • 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 are set appropriately. Do not allow unauthorized users to read a file, to change a file, to list the contents of a directory, or to add to a directory.

Your site might provide additional suggestions.

Email Usage Guidelines

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

Warn users not to trust email with instructions that purport to come from an administrator. Doing so 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.

Password Enforcement

The System Administrator role must specify a unique user name and user ID when creating a new account. When choosing the name and ID for a new account, you must ensure that both the user name and associated ID are not duplicated anywhere on the network and have not been previously used. See also Passwords and Password Policy.

    The Security Administrator role is responsible for specifying the original password for each account and for communicating the passwords to users of new accounts. You must consider the following information when administering passwords:

  • 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 practice ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if all other accounts are locked.

  • Communicate the password to the user of a new account in such a way that the password cannot be eavesdropped by anyone else.

  • Change an account's password if you have any suspicion that the password has been discovered by someone who should not know it.

  • Never reuse user names or user IDs over the lifetime of the system.

      Ensuring that user names and user IDs are not reused prevents possible confusion about the following:

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

    • Which user owns which files when archived files are restored

Information Protection

    You as an administrator are responsible for correctly setting up and maintaining discretionary access control (DAC) and mandatory access control (MAC) protections for security-critical files. Critical files include the following:

  • shadow file – Contains encrypted passwords. See the shadow(4) man page.

  • auth_attr file – Contains custom authorizations. See the auth_attr(4) man page.

  • prof_attr file – Contains custom rights profiles. See the prof_attr(4) man page.

  • exec_attr file – Contains commands with security attributes that the site has added to rights profiles. See the exec_attr(4) man page.

  • Audit trail – Contains the audit records that the audit service has collected. See the audit.log(4) man page.

Password Protection

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 /etc/shadow file, which is readable only by root. For more information, see the shadow(4) man page.

Group Administration Practices

The System Administrator role 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 System 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.

User Deletion Practices

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

  • Delete the account's home directories in every zone.

  • Delete any processes or jobs that are owned by the deleted account:

    • Delete any objects that are owned by the account, or assign the ownership to another user.

    • Delete any at or batch jobs that are scheduled on behalf of the user. For details, see the at(1) and crontab(1) man pages.

  • Never reuse the user name or user ID.