Securing Users

At this point, only the initial user who can assume the root role has access to the system. The following tasks are best performed in order before regular users can log in.

Set Stronger Password Constraints

Use this procedure if the defaults do not satisfy your site security requirements. The steps follow the list of entries in the /etc/default/passwd file.

Before You Begin

Before changing the defaults, ensure that the changes allow all users to authenticate to their applications and to other systems on the network.

You must be in the root role.

• Edit the /etc/default/passwd file.
  1. Require users to change their passwords every month, but not more frequently than every three weeks.

     ## /etc/default/passwd
     ##
     MAXWEEKS=
     MINWEEKS=
     MAXWEEKS=4
     MINWEEKS=3

  2. Require a password of at least eight characters.

     #PASSLENGTH=6
     PASSLENGTH=8

  3. Keep a password history.

     #HISTORY=0
     HISTORY=10

  4. Require a minimum difference from the last password.

     #MINDIFF=3
     MINDIFF=4

  5. Require at least one uppercase letter.

     #MINUPPER=0
     MINUPPER=1

  6. Require at least one digit.

     #MINDIGIT=0
     MINDIGIT=1

See Also

• For the list of variables that constrain password creation, see the /etc/default/passwd file. The defaults are indicated in the file.

• For the password constraints in effect after installation, see System Access Is Limited and Monitored.

• passwd(1) man page

Set Account Locking for Regular Users

Use this procedure to lock regular user accounts after a certain number of failed login attempts.

Before You Begin

You must be in the root role. Do not set this protection system-wide on a system that you use for administrative activities.

1. Set the LOCK_AFTER_RETRIES security attribute to YES.
   • Set system-wide.

     # vi /etc/security/policy.conf
     ...
     #LOCK_AFTER_RETRIES=NO
     LOCK_AFTER_RETRIES=YES
     ...

   • Set per user.

     # usermod -K lock_after_retries=yes username

2. Set the RETRIES security attribute to 3.

   # vi /etc/default/login
   ...
   #RETRIES=5
   RETRIES=3
   ...

See Also

• For a discussion of user and role security attributes, see Chapter 10, Security Attributes in Oracle Solaris (Reference), in Oracle Solaris Administration: Security Services.

• Selected man pages include policy.conf(4) and user_attr(4).

Set More Restrictive umask Value for Regular Users

If the default umask value, 022, is not restrictive enough, set a more restrictive mask by using this procedure.

Before You Begin

You must be in the root role.

• Modify the umask value in the login profiles in the skeleton directories for the various shells.

  Oracle Solaris provides directories for administrators to customize user shell defaults. These skeleton directories include files such as .profile, .bashrc and .kshrc.

  Choose one of the following values:

  • umask 027 – Provides moderate file protection

    (740) – w for group, rwx for others

  • umask 026 – Provides slightly stricter file protection

    (741) – w for group, rw for others

  • umask 077 – Provides complete file protection

    (700) – No access for group or others

See Also

For more information, see the following:

• Setting Up User Accounts in Oracle Solaris Administration: Common Tasks

• Default umask Value in Oracle Solaris Administration: Security Services

• Selected man pages include usermod(1M) and umask(1).

Audit Significant Events in Addition to Login/Logout

Use this procedure to audit administrative commands, attempts to invade the system, and other significant events as specified by your site security policy.

Before You Begin

You must be in the root role. You are implementing your site's security policy with regard to auditing.

1. Audit all uses of privileged commands by users and roles.

   For all users and roles, add the AUE_PFEXEC audit event to their preselection mask.

   # usermod -K audit_flags=lo,ps:no username

   # rolemod -K audit_flags=lo,ps:no rolename

2. Record the arguments to audited commands.

   # auditconfig -setpolicy +argv

3. Record the environment in which audited commands are executed.

   # auditconfig -setpolicy +arge

See Also

• For information about audit policy, see Audit Policy in Oracle Solaris Administration: Security Services.

• For examples of setting audit flags, see Configuring the Audit Service (Tasks) in Oracle Solaris Administration: Security Services and Troubleshooting the Audit Service (Tasks) in Oracle Solaris Administration: Security Services.

• To configure auditing, see the auditconfig(1M) man page.

Monitor lo Events in Real Time

Use this procedure to activate the audit_syslog plugin for events that you want to monitor as they happen.

Before You Begin

You must be in the root role to modify the syslog.conf file. Other steps require you to be assigned the Audit Configuration rights profile.

1. Send the lo class to the audit_syslog plugin, and make the plugin active.

   # auditconfig -setplugin audit_syslog active p_flags=lo

2. Add an audit.notice entry to the syslog.conf file.

   The default entry includes the location of the log file.

   # cat /etc/syslog.conf
   …
   audit.notice       /var/adm/auditlog

3. Create the log file.

   # touch /var/adm/auditlog

4. Refresh the configuration information for the syslog service.

   # svcadm refresh system/system-log

5. Refresh the audit service.

   The audit service reads the changes to the audit plugin upon refresh.

   # audit -s

See Also

• To send the audit summaries to another system, see the example following How to Configure syslog Audit Logs in Oracle Solaris Administration: Security Services.

• The audit service can generate extensive output. To manage the logs, see the logadm(1M) man page.

• To monitor the output, see Monitoring audit_syslog Audit Summaries.

Remove Unneeded Basic Privileges From Users

Under particular circumstances, one or more of three basic privileges can be removed from a regular user's basic set.

• file_link_any – Allows a process to create hard links to files owned by a UID different from the effective UID of the process.

• proc_info – Allows a process to examine the status of processes other than those it can send signals to. Processes that cannot be examined cannot be seen in /proc and appear not to exist.

• proc_session – Allows a process to send signals or trace processes outside its session.

Before You Begin

You must be in the root role.

1. Prevent a user from linking to a file that the user does not own.

   # usermod -K defaultpriv=basic,!file_link_any user

2. Prevent a user from examining processes that the user does not own.

   # usermod -K defaultpriv=basic,!proc_info user

3. Prevent a user from starting a second session, such as starting an ssh session, from the user's current session.

   # usermod -K defaultpriv=basic,!proc_session user

4. Remove all three privileges from a user's basic set.

   # usermod -K defaultpriv=basic,!file_link_any,!proc_info,!proc_session user

See Also

For more information, see Chapter 8, Using Roles and Privileges (Overview), in Oracle Solaris Administration: Security Services and the privileges(5) man page.