Managing Privileges

The most secure way to manage privileges for users and roles is to confine use of privilege to commands in a rights profile. The rights profile is then included in a role. The role is assigned to a user. When the user assumes the assigned role, the privileged commands are available to be run in a profile shell. The following procedures show how to assign privileges, remove privileges, and debug privilege use.

How to Determine the Privileges on a Process

This procedure shows how to determine which privileges are available to your processes. The listing does not include privileges that have been assigned to particular commands.

• List the privileges that are available to your shell's process.

  % ppriv pid
  $ ppriv -v pid

  pid

  Is the process number. Use a double dollar sign ($$) to pass the process number of the parent shell to the command.

  -v

  Provides a verbose listing of the privilege names.

Example 11-1 Determining the Privileges in Your Current Shell

In the following example, the privileges in the parent process of the user's shell process are listed. In the second example, the full names of the privileges are listed. The single letters in the output refer to the following privilege sets:

E

Is the effective privilege set.

I

Is the inheritable privilege set.

P

Is the permitted privilege set.

L

Is the limit privilege set.

% ppriv $$
1200:   -csh
flags = <none>
        E: basic
        I: basic
        P: basic
        L: all
% ppriv -v $$
1200:   -csh
flags = <none>
        E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

Example 11-2 Determining the Privileges of a Role That You Can Assume

Roles use an administrative shell, or profile shell. You must assume a role and use the role's shell to list the privileges that have been directly assigned to the role. In the following example, the role sysadmin has no directly assigned privileges.

% su - sysadmin
Password: <Type sysadmin password>
$ /usr/ucb/whoami
sysadmin
$ ppriv -v $$
1400:   pfksh
flags = <none>
        E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

How to Determine Which Privileges a Program Requires

This procedure determines which privileges a command or process requires to succeed.

Before You Begin

The command or process must have failed for this procedure to work.

1. Type the command that is failing as an argument to the ppriv debugging command.

   % ppriv -eD touch /etc/acct/yearly
   touch[11365]: missing privilege "file_dac_write" 
        (euid = 130, syscall = 224) needed at ufs_direnter_cm+0x27c
   touch: /etc/acct/yearly cannot create

2. Determine which system call is failing by finding the syscall number in the /etc/name_to_sysnum file.

   % grep 224 /etc/name_to_sysnum
   creat64                 224

Example 11-3 Using the truss Command to Examine Privilege Use

The truss command can debug privilege use in a regular shell. For example, the following command debugs the failing touch process:

% truss -t creat touch /etc/acct/yearly
creat64("/etc/acct/yearly", 0666)            
                       Err#13 EACCES [file_dac_write]
touch: /etc/acct/yearly cannot create

The extended /proc interfaces report the missing privilege after the error code in truss output.

Example 11-4 Using the ppriv Command to Examine Privilege Use in a Profile Shell

The ppriv command can debug privilege use in a profile shell. If you assign a rights profile to a user, and the rights profile includes commands with privileges, the commands must be typed in a profile shell. When the privileged commands are typed in a regular shell, the commands do not execute with privilege.

In this example, the jdoe user can assume the role objadmin. The objadmin role includes the Object Access Management rights profile. This rights profile allows the objadmin role to change permissions on files that objadmin does not own.

In the following excerpt, jdoe fails to change the permissions on the useful.script file:

jdoe% ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Mar 11 05:29 useful.script
jdoe% chown objadmin useful.script
chown: useful.script: Not owner
jdoe% ppriv -eD chown objadmin useful.script
chown[11444]: missing privilege "file_chown" 
            (euid = 130, syscall = 16) needed at ufs_setattr+0x258
chown: useful.script: Not owner

When jdoe assumes the objadmin role, the permissions on the file are changed:

jdoe% su - objadmin
Password: <Type objadmin password>
$ ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Mar 11 05:29 useful.script
$ chown objadmin useful.script
$ ls -l useful.script
-rw-r--r--  1 objadmin  staff  2303 Mar 11 05:29 useful.script
$ chgrp admin useful.script
$ ls -l objadmin.script
-rw-r--r--  1 objadmin  admin  2303 Mar 11 05:31 useful.script

Example 11-5 Changing a File Owned by the root User

This example illustrates the protections against privilege escalation. For a discussion, see Prevention of Privilege Escalation. The file is owned by the root user. The less powerful role, objadmin role needs all privileges to change the file's ownership, so the operation fails.

jdoe% su - objadmin
Password: <Type objadmin password>
$ cd /etc; ls -l system
-rw-r--r--  1 root  sys   1883 Mar 20 14:04 system
$ chown objadmin system
chown: system: Not owner
$ ppriv -eD chown objadmin system
chown[11481]: missing privilege "ALL" 
     (euid = 101, syscall = 16) needed at ufs_setattr+0x258
chown: system: Not owner

How to Add Privileges to a Command

You add privileges to a command when you are adding the command to a rights profile. The privileges enable the role that includes the rights profile to run the administrative command, while not gaining any other superuser capabilities.

Before You Begin

The command or program must be privilege-aware. For a fuller discussion, see How Processes Get Privileges.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Open the Solaris Management Console GUI.

   For instructions, see How to Assume a Role in the Solaris Management Console.

3. Use the Rights tool to update an appropriate profile.

   Select the command to include. For each included command, add the privileges that the command requires.

   ---

   Caution - When you include commands in a rights profile and add privileges to the commands, the commands execute with those privileges when the commands are run in a profile shell.

   The order of profiles is important. The profile shell executes a command or action with the security attributes that are specified in the earliest profile in the account's list of profiles. For example, if the chgrp command is in the Object Access Management rights profile with privileges, and Object Access Management is the first profile in which the chgrp command is found, then the chgrp command executes with the privileges specified in the Object Access Management profile.

   ---

How to Assign Privileges to a User or Role

You might trust some users with a particular privilege all the time. Very specific privileges that affect a small part of the system are good candidates for assigning to a user. For a discussion of the implications of directly assigned privileges, see Security Considerations When Directly Assigning Security Attributes.

The following procedure enables user jdoe to use high resolution timers.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Add the privilege that affects high resolution times to the user's initial inheritable set of privileges.

   $ usermod -K defaultpriv=basic,proc_clock_highres jdoe

3. Read the resulting user_attr entry.

   $ grep jdoe /etc/user_attr
   jdoe::::type=normal;defaultpriv=basic,proc_clock_highres

Example 11-6 Creating a Role With Privileges to Configure System Time

In this example, a role is created whose only task is to handle time on the system.

$ /usr/sadm/bin/smrole -D nisplus:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
add -- -n clockmgr \
-c "Role that sets system time" \
-F "Clock Manager" \
-s /bin/pfksh \
-u 108 \
-P <Type clockmgr password> \
-K defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

The -K line is wrapped for display purposes.

If the role was created locally, the user_attr entry for the role would appear similar to the following:

clockmgr:::Role that sets system time:
type=role;defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

How to Limit a User's or Role's Privileges

You can limit the privileges that are available to a user or role by reducing the basic set, or by reducing the limit set. You should have good reason to limit the user's privileges in this way, because such limitations can have unintended side effects.

---

Caution - You should thoroughly test any user's capabilities where the basic set or the limit set has been modified for a user.

• When the basic set is less than the default, users can be prevented from using the system.

• When the limit set is less than all privileges, processes that need to run with an effective UID=0 might fail.

---

1. Determine the privileges in a user's basic set and limit set.

   For the procedure, see How to Determine the Privileges on a Process.

2. (Optional) Remove one of the privileges from the basic set.

   $ usermod -K defaultpriv=basic,!priv-name username

   By removing the proc_session privilege, you prevent the user from examining any processes outside the user's current session. By removing the file_link_any privilege, you prevent the user from making hard links to files that are not owned by the user.

   ---

   Caution - Do not remove the proc_fork or the proc_exec privilege. Without these privileges, the user would not be able to use the system. In fact, these two privileges are only reasonably removed from daemons that should not fork() or exec() other processes.

   ---

3. (Optional) Remove one of the privileges from the limit set.

   $ usermod -K limitpriv=all,!priv-name username

4. Test the capabilities of username.

   Log in as username and try to perform the tasks that username must perform on the system.

Example 11-7 Removing Privileges From a User's Limit Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the sys_linkdir privilege. That is, the user cannot make hard links to directories, nor can the user unlink directories, even after the user runs the su command.

$ usermod -K limitpriv=all,!sys_linkdir jdoe
$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic;limitpriv=all,!sys_linkdir

Example 11-8 Removing Privileges From a User's Basic Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the proc_session privilege. That is, the user cannot examine any processes outside the user's session, even after the user runs the su command.

$ usermod -K defaultpriv=basic,!proc_session jdoe

$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic,!proc_session;limitpriv=all

How to Run a Shell Script With Privileged Commands

---

Note - When you create a shell script that runs commands with inherited privileges, the appropriate rights profile must contain the commands with privileges assigned to them.

---

1. Start the script with /bin/pfsh, or any other profile shell, on the first line.

   #!/bin/pfsh
   # Copyright (c) 2003 by Sun Microsystems, Inc.

2. Determine the privileges that the commands in the script need.

   % ppriv -eD script-full-path

3. Open the Solaris Management Console GUI.

   For instructions, see How to Assume a Role in the Solaris Management Console. Choose a role, such as Primary Administrator, that can create a rights profile.

4. Use the Rights tool to create or update an appropriate profile.

   Select the script, and include in the rights profile each of the commands in the shell script that need privileges to run. For each included command, add the privileges that the command requires.

   ---

   Caution - The order of rights profiles is important. The profile shell executes the earliest instance of a command in the list of profiles. For example, if the chgrp command is in the Object Access Management rights profile, and Object Access Management is the first profile in which the chgrp command is found, then the chgrp command executes with the privileges that are specified in the Object Access Management profile.

   ---

5. Add the rights profile to a role and assign the role to a user.

   To execute the profile, the user assumes the role and runs the script in the role's profile shell.