Go to main content

Securing Users and Processes in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020

How to Troubleshoot Rights Assignments

Several factors can affect why rights are not being evaluated and correctly applied. This procedure helps you debug why assigned rights might not be available to users, roles, or processes. Several of the steps are based on Order of Search for Assigned Rights.

Before You Begin

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

  1. Verify and restart the naming service.
    1. Verify that the security assignments for the user or role are in the naming service that is enabled on the system.
      # svccfg -s name-service/switch
      listprop config
      config                      application
      config/value_authorization  astring  solaris.smf.value.name-service.switch
      config/default              astring  files ldap
      config/host                 astring  "files dns mdns ldap"
      config/netgroup             astring  ldap
      config/printer              astring  "user files"

      In this output, all services that are not explicitly mentioned inherit the value of the default, files ldap. Therefore, passwd and its related attribute databases, user_attr, auth_attr, and prof_attr, are searched first in files, then in LDAP.

    2. Restart the name service cache, svc:/system/name-service/cache.

      The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the naming service with current data.

      # svcadm restart name-service/cache
  2. Determine where a right is assigned to the user by running the userattr -v command.

    Run the command once for every attribute. For example, the following commands indicate which rights are assigned and where the assignment was made for the user jdoe. The lack of output indicates that jdoe is using the defaults.

    $ userattr -v access_times jdoe
    $ userattr -v access_tz jdoe
    $ userattr -v annotation jdoe
    $ userattr -v auth_profiles jdoe
    $ userattr -v defaultpriv jdoe
    $ userattr -v limitpriv jdoe
    $ userattr -v idlecmd jdoe
    $ userattr -v idletime jdoe
    $ userattr -v lock_after_retries jdoe
    $ userattr -v pam_policy jdoe
    $ userattr -v unlock_after jdoe
    $ userattr -v auths jdoe Output indicates authorizations from rights profiles
    Basic Solaris User :solaris.mail.mailq,solaris.network.autoconf.read,
    Console User :solaris.system.shutdown,solaris.device.cdrw,
    $ userattr -v audit_flags jdoe
    user_attr: fw:no Output indicates jdoe is individually assigned audit flags
    $ userattr -v profiles jdoe
    user_attr: Audit Review,Stop Output indicates two assigned rights profiles
    $ userattr roles jdoe 
    user_attr : cryptomgt,infosec Output indicates two assigned roles

      The output indicates that jdoe is directly assigned audit flags, two rights profiles, and two roles. The assigned authorizations are from default rights profiles, set either in the account-policy SMF stencil or in files in the /etc directory. To determine the source of the default rights profiles on your system, see New Feature – Enabling the account-policy Service.

    • Because jdoe is directly assigned audit flags, no audit flag values in the rights profiles will be used.

    • The rights profiles are evaluated in order, first the Audit Review rights profile, then the Stop profile.

    • All other rights are assigned to jdoe in the roles cryptomgt and infosec. To view those rights, jdoe must assume each role, then list the rights.

    Tip  -  If the useradm package is installed, you can run the useradm list jdoe command to view the rights that are directly assigned. See Listing All Rights Assigned to a User.

    If the right is not directly assigned to the user, continue with the following checks.

  3. Verify that the assigned authorizations are spelled correctly.

    The source of an authorization assignment is not important because authorizations accumulate for users. However, a misspelled authorization fails silently.

  4. For rights profiles that you have created, verify that you have assigned the appropriate security attributes to the commands in that profile.

    For example, some commands require uid=0 rather than euid=0 to succeed. Review the man page for the command to determine whether the command or any of its options require authorizations.

  5. Check the rights in the user's rights profiles.
    1. In order, check for the rights in the list of authenticated rights profiles.

      The value of the attribute in the earliest rights profile in the list is the value in the kernel. If this value is incorrect, either change the value in that rights profile, or reassign the profiles in the correct order. See How to Reorder Assigned Rights.

      For privileged commands, check that the privileges are not removed from the defaultpriv or limitpriv keyword.

    2. In order, check for the rights in the list of regular rights profiles.

      Follow the same checks as you performed for authenticated rights profiles.

    3. If the rights you are searching for are not listed, check the roles that the user is assigned.

      If the right is assigned to a role, the user must assume the role to obtain the rights.

  6. Check whether a failed command requires authorizations to succeed.
    1. Check whether an existing rights profile includes the required authorization.

      If the profile exists, use it. Assign it to the user as an authenticated rights profile or a regular rights profile. Order the profile before any other rights profile that includes the command that requires this authorization to succeed.

    2. Check whether an option to the command requires authorization.

      Assign the privilege to the command that requires it, add the required authorizations, place the command and authorizations in a rights profile, and assign the profile to the user.

  7. If a command continues to fail for a user, verify that the user is executing the command in a profile shell.

    Administrative commands must be executed in a profile shell. Example 76, Determining Whether You Are Using a Profile Shell shows how to test for a profile shell.

      To reduce the likelihood of user error, you can try the following:

    • Assign a profile shell as the user's login shell.

    • Instruct users to precede all privileged commands with the pfexec command.

    • Remind the user to run administrative commands in a profile shell.

    • If your site is using roles, remind the user to assume the role before running administrative commands. For an example of successful command execution as a role rather than as a user, see Example 78, Running the Privileged Commands in Your Role.

  8. If a command fails for a role, assume the role and perform the same steps that you performed when checking for a user's rights.
Example 76  Determining Whether You Are Using a Profile Shell

When a privileged command does not work, the user tests for the PRIV_PFEXEC flag, then runs the command. The error message might not indicate that the problem is a privilege problem.

$ praudit 20120814200247.20120912213421.example-system
praudit: Cannot associate stdin with 20120814200247.20120912213421.example-system: 
Permission denied

$ ppriv $$
107219: bash
flags = <none>

$ pfbash
$ ppriv $$
1072232: bash

$ praudit 20120814200247.20120912213421.example-system 
/** Command succeeds **/
Example 77  Determining the Privileged Commands of a Role

In this example, a user assumes an assigned role and lists the rights that are included in one of the rights profiles. The rights are truncated to emphasize the commands.

$ roles

$ su - devadmin
Password: xxxxxxxx

$ profiles -l
Device Security
	profiles=Service Configuration
          /usr/sbin/add_drv          uid=0
          /usr/sbin/devfsadm         uid=0
          /usr/sbin/eeprom           uid=0
          /usr/sbin/list_devices     euid=0
          /usr/sbin/rem_drv          uid=0
          /usr/sbin/strace           euid=0
          /usr/sbin/update_drv       uid=0
          /usr/sbin/add_allocatable  euid=0
          /usr/sbin/remove_allocatable   euid=0
Service Configuration
Example 78  Running the Privileged Commands in Your Role

In the following example, the admin role can change the permissions on the useful.script file.

$ whoami
$ ls -l useful.script
-rwxr-xr-- 1 elsee eng 262 Apr 2 10:52 useful.script

$ chgrp admin useful.script
chgrp: useful.script: Insufficient privileges

$ su - admin
Password: xxxxxxxx

$ chgrp admin useful.script
$ chown admin useful.script
$ ls -l useful.script
-rwxr-xr-- 1 admin admin 262 Apr 2 10:53 useful.script