Go to main content

Securing Users and Processes in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020

Using Your Assigned Administrative Rights

In the root role, the initial user has all administrative rights. As root, this user can assign administrative rights, such as a role, a rights profile, or specific privileges and authorizations to trusted users. This section describes how these users can use their assigned rights.

Note -  Oracle Solaris provides a special editor for administrative files. When editing administrative files, use the pfedit command. Example 44, Editing a System File shows how to enable non-root users to edit specified system files.

    To perform your administrative tasks, open a terminal window and choose from the following options:

  • If you are using sudo, type the sudo command.

    For administrators who are familiar with the sudo command, run the command with the name of an administrative command that you are assigned in the sudoers file. For more information, see the sudo(8) and sudoers(5) man pages.

  • If your task requires superuser privileges, become root.

    $ su -
    Password: xxxxxxxx

    Note -  This command works whether root is a user or a role. The pound sign (#) prompt indicates that you are now root.
  • If your task is assigned to a role, assume the role that can perform that task.

    In the following example, you assume an audit configuration role. This role includes the Audit Configuration rights profile. You received the role password from your administrator.

    $ su - audadmin
    Password: xxxxxxxx

    Tip  -  If you did not receive a role password, your administrator has configured the role to require your user password. Type your user password to assume the role. For more information about this option, see Example 18, Enabling a User to Use Own Password for Role Password.

    The shell in which you typed this command is now a profile shell. In this shell, you can run the auditconfig command. For more about profile shells, see Profile Shells and Rights Verification.

    Tip  -  To view the rights of your role, see Listing Rights Profiles.
  • If your task is assigned directly to you as a user and you are not running a profile shell as described in Example 76, Determining Whether You Are Using a Profile Shell, create a profile shell in one of the following ways:

    • Use the pfbash command to create a shell that evaluates administrative rights.

      In the following example, you have been directly assigned the Audit Configuration rights profile. The following set of commands enables you to view audit preselection values and audit policy in the pfbash profile shell:

      $ pfbash
      $ auditconfig -getflags
      active user default audit flags = ua,ap,lo(0x45000,0x45000)
      configured user default audit flags = ua,ap,lo(0x45000,0x45000)
      $ auditconfig -getpolicy
      configured audit policies = cnt
      active audit policies = cnt
    • Use the pfexec command to run one administrative command.

      In the following example, you have been directly assigned the Audit Configuration rights profile as an authenticated rights profile. You can run a privileged command from this profile by using the pfexec command with the name of that command. For example, you can view the user's preselected audit flags:

      $ pfexec auditconfig -getflags
      Enter password: Type your user password
      active user default audit flags = ua,ap,lo(0x45000,0x45000)
      configured user default audit flags = ua,ap,lo(0x45000,0x45000)

      Typically, to run another privileged command that is included in your rights, you must type pfexec again before you type the privileged command. For more information, see the pfexec(1) man page. If you are configured with password caching, you can run subsequent commands within a configurable interval without providing a password, as shown in Example 45, Caching Authentication for Ease of Role Use.

Example 44  Editing a System File

If you are not root with the UID of 0, by default you cannot edit system files. However, if you are assigned the solaris.admin.edit/path-to-system-file authorization, you can edit system-file. For example, if you are assigned the solaris.admin.edit/etc/security/audit_warn authorization, you can edit the audit_warn file by using the pfedit command.

# pfedit /etc/security/audit_warn

For more information, see the pfedit (4) man page. This command is for use by all administrators.

Example 45  Caching Authentication for Ease of Role Use

In this example, the administrator configures a role to manage audit configuration, but provides ease of use by caching the user's authentication. First, the administrator creates and assigns the role.

# roleadd -K roleauth=user -K profiles="Audit Configuration" audadmin
# usermod -R +audadmin jdoe

When jdoe uses the –c option when switching to the role, a password is required before the auditconfig output is displayed:

$ su - audadmin -c auditconfig option
Password: xxxxxxxx 
auditconfig output

If authentication is not being cached, when jdoe runs the command again, a password prompt appears.

The administrator creates a file in the pam.d directory to hold an su stack that enables the caching of authentication. When authentication is cached, a password is initially required but not thereafter until a certain amount of time has passed.

$ pfedit /etc/pam.d/su
## Cache authentication for switched user
auth required           pam_unix_cred.so.1
auth sufficient         pam_tty_tickets.so.1
auth requisite          pam_authtok_get.so.1
auth required           pam_dhkeys.so.1
auth required           pam_unix_auth.so.1

After creating the file, the administrator checks the entries for typos, omissions, or repetitions.

The administrator must provide the entire preceding su stack. The pam_tty_tickets.so.1 module implements the cache. For more about PAM, see the pam_tty_tickets(7) and pam.conf(5) man pages and Chapter 1, Using Pluggable Authentication Modules in Managing Authentication in Oracle Solaris 11.4.

After the administrator adds the su PAM file and reboots the system, all roles including the audadmin role are prompted only once for a password when running a series of commands.

$ su - audadmin -c auditconfig option
Password: xxxxxxxx 
auditconfig output
$ su - audadmin -c auditconfig option 
auditconfig output
Example 46  Assuming the root Role

In the following example, the initial user assumes the root role and lists the privileges in the role's shell.

$ roles
$ su - root
Password: xxxxxxxx
# Prompt changes to root prompt
# ppriv $$
1200:   pfksh
flags = <none>
        E: all
        I: basic
        P: all
        L: all

For information about privileges, see Process Rights Management and the ppriv(1) man page.

Example 47  Assuming an ARMOR Role

In this example, the user assumes an ARMOR role that the administrator assigned.

In a terminal window, the user determines which roles are assigned.

$ roles

The user then assumes the fsadm role and supplies the user's password.

$ su - fsadm
Password: xxxxxxxx

The su - rolename command changes the terminal's shell to a profile shell. The user is now the fsadm role in this terminal window.

To determine which commands can be run in this role, the user follows the instructions in Listing Rights Profiles.