Go to main content

Securing Users and Processes in Oracle® Solaris 11.4

Exit Print View

Updated: October 2019
 
 

Setting General User Restrictions

In this section, you change the default umask value for all users, prevent malicious login attempts by limiting failed logins, and remove the ability of console users to shut down the system. You can limit failed login attempts per system, per user, or through a rights profile. For a discussion of password constraints, see Passwords and Password Policy in Oracle Solaris 11.4 Security and Hardening Guidelines.

How to Set a More Restrictive umask Value for Regular Users

The umask utility sets the file permission bits of user-created files. If the default umask value, 022, is not restrictive enough, set a more restrictive mask by using this procedure.

Before You Begin

You must become an administrator who is authorized to edit the skeleton files. The root role is assigned these authorizations. For more information, see Using Your Assigned Administrative Rights.

  1. View the sample files that Oracle Solaris provides for user shell defaults.
    # ls -1a /etc/skel
    .bashrc
    .profile
    local.cshrc
    local.login
    local.profile
  2. Set the umask value in the /etc/skel files that you are going to assign to users.

      Choose one of the following values:

    • umask 026 – Provides moderate file protection

      (751) – r for group, x for others

    • umask 027 – Provides strict file protection

      (750) – r for group, no access for others

    • umask 077 – Provides complete file protection

      (700) – No access for group or others

See Also

For more information, see the following:

How to Set Account Locking for Regular Users

Use this procedure to lock regular user accounts after a certain number of failed login attempts. You can set account locking per user, per system, or for selected users through a rights profile.


Note -  Roles are shared accounts. Do not set account locking for users who can assume roles or roles because one locked user can lock out the role.

Before You Begin

Do not set this protection system-wide on a system that you use for administrative activities. Rather, monitor the administrative system for unusual use and keep it available for administrators.

You must assume the root role. For more information, see Using Your Assigned Administrative Rights.

  1. Set the LOCK_AFTER_RETRIES security attribute to YES.

    Choose the scope of the attribute value.

    • Set system-wide.
      • Modify the security attribute in SMF.

        For the procedure, see Modifying Login Policy.

      • DEPRECATED. Edit a system security file.
        # pfedit /etc/security/policy.conf
        ...
        #LOCK_AFTER_RETRIES=NO
        LOCK_AFTER_RETRIES=YES
        ...
    • Set per user.

      This protection applies only to the user for whom you run this command. If you have many users, this is not a scalable solution.

      # usermod -K lock_after_retries=yes username
    • Create and assign a rights profile.

      This protection applies to any user or system where you assign this rights profile.

      1. Create the rights profile.
        # profiles -p shared-profile -S ldap
        shared-profile: set lock_after_retries=yes
        ...

        For more information about creating rights profiles, see Creating Rights Profiles and Authorizations.

      2. Assign the rights profile to users or system-wide.

        If you have many users that share a rights profile, setting this value in a rights profile can be a scalable solution.

        # usermod -P shared-profile username

        You can also assign the profile per system in the policy.conf file.

        # pfedit /etc/security/policy.conf
        ...
        #PROFS_GRANTED=Basic Solaris User
        PROFS_GRANTED=shared-profile,Basic Solaris User
  2. Set the RETRIES security attribute to 3.

    Choose the scope of the attribute value.

    • Set system-wide.
      • Modify the security attribute in SMF.

        For the procedure, see Modifying Login Policy.

      • DEPRECATED. Edit a system security file.
        # pfedit /etc/default/login
        ...
        #RETRIES=5
        RETRIES=3
        ...
    • Set per user.
      # usermod -K lock_after_retries=3 username
    • Create and assign a rights profile.

      Review Creating Rights Profiles and Authorizations and create a rights profile that includes lock_after_retries=3.

  3. (Optional) Specify a time after which a user can re-authenticate to a locked account.
    # usermod -K unlock_after=185m username

    This user can log in without administrative intervention three hours and five minutes after the account locks.

  4. To unlock a locked user, use the passwd command.
    # passwd -u username

    A user who is locked out cannot log in without administrative intervention. You can unlock user accounts in both the files and ldap naming services.

See Also

How to Remove Power Management Capability From Users

Use this procedure to prevent users on the console of a system from suspending the system or powering it down. This software solution is not effective if the system hardware can be unplugged by the console user.

Before You Begin

You must assume the root role. For more information, see Using Your Assigned Administrative Rights.

  1. Review the contents of the Console User rights profile.
    $ profiles -p "Console User" info
    	name=Console User
    	desc=Manage System as the Console User
    	auths=solaris.system.shutdown,solaris.device.cdrw,
                  solaris.smf.manage.vbiosd,solaris.smf.value.vbiosd
    	profiles=Suspend To RAM,Suspend To Disk,Brightness,CPU Power Management,
                     Network Autoconf User
  2. Create a rights profile that includes any rights in the Console User profile that you want users to retain.

    For instructions, see How to Create a Rights Profile.

    The following is a sample replacement profile:

    $ profiles -p "Site Console User" info
    	name=Site Console User
    	desc=Read devices and control brightness on the console
    	auths=solaris.device.cdrw,
    	profiles=Brightness,CPU Power Management,Network Autoconf User
  3. Comment out the Console User rights profile in the /etc/security/policy.conf file.
    #CONSOLE_USER=Console User
  4. Assign the rights profile that you created in Step 2.
    • Assign this rights profile to users.

      # usermod -P shared-profile username
    • You can also assign the profile per system, either in SMF or in the policy.conf file.

      • If the account-policy service is enabled, assign the profile in SMF, as shown in Example 35, Adding a Rights Profile to Every Login.

      • DEPRECATED. If the account-policy service is not enabled, edit the policy.conf file.

        # pfedit /etc/security/policy.conf...
        #PROFS_GRANTED=Basic Solaris User
        PROFS_GRANTED=shared-profile,Basic Solaris User

See Also

For more information, see the account-policy(8S), policy.conf(5) and usermod(8) man pages.