Trusted Solaris Administrator's Procedures

To Find Out Which Privileges a Program Needs

Assume the Security Administrator role and go to an ADMIN_LOW workspace.

(OPTIONAL) Create a Privilege Debug profile and assign it to an administrative role.

Note -
The Security Administrator role is the only role assigned the runpd command in the default configuration. The administrative role that can be created in this step could be used exclusively for privilege debugging. The role can be used to find out what privileges a command needs when run by a normal user at a label within the user accreditation range or by an administrative role at one of the administrative labels.
1. In the appropriate scope, launch the SMC and use the Rights tool to create a new rights profile (such as Privilege Debug).
  
  Give the new profile the commands: /usr/sbin/runpd, /bin/getfpriv, and /bin/setfpriv, the authorizations: Shutdown the System, Enable Login, and Set File Privilege, and the action: Admin Editor. The profile enables an administrative role to enable privilege debugging and execute the /usr/sbin/runpd command.
2. If desired, use the Administrative Roles tool to create an administrative role (such as PrivDebug).
3. Assign the role the new profile and the All profile, if desired.
  
  Place the more restrictive rights profile, Privilege Debug, before the less restrictive profile, All.
4. If you created a new role, open the User Accounts tool and assign the privilege PrivDebug role to an account.

Assume the new role, or stay in the Security Administrator role.

Use the Admin Editor action to change the tsol_privs_debug setting to 1 in the /etc/system file.
set tsol_privs_debug=1

Use the Admin Editor action to remove the comment (#) at the beginning of the line that begins kern.debug in the /etc/syslog.conf file.

The following line logs the privileges requested by system calls and daemons in the /var/log/privdebug.log file.
kern.debug;daemon.debug;local0.debug /var/log/privdebug.log

Reboot to enable privilege debugging.

Log in and assume the Security Administrator role or, if you created a new privilege debugging role in Step 2, assume the new role.

Create a workspace at the label at which the test program will typically be run.

In a terminal at the appropriate label, enter the runpd command followed by the name of the command and any options whose use of privilege you want to check.

As shown in the following example, runpd displays the name of the privilege(s) that the program needs in order to succeed followed by the type of access attempted (for example, create) followed by the name of the resource (for example, RAW_SOCKET).

$ runpd pathname_of_command_and_any_options

runpd: child terminated with a status of 0

process pathname_of_command pid process_ID 
lacking privilege privilege_name
to perform type_of_access 
upon resource resource_name (MM DD HH:MM)

The following example shows the result of running runpd(1M) on ping(1M) (for the purpose of the example, Trusted Solaris privileges were removed from the command).

$ runpd /usr/sbin/ping sif 
sif is alive runpd: child terminated with a status of 0 
process /usr/sbin/ping pid 5138 lacking privilege net_rawaccess 
to create raw socket (Oct 25 18:33) 
process /usr/sbin/ping pid 5138 lacking privilege 
sys_net_config to manage transport opts (Oct 25 18:33)

Open an ADMIN_HIGH workspace, and check the log file for the privilege debugging messages.

A typical privilege debugging log entry is similar to the following:

$ cat /var/log/privdebug.log
Mar 29 12:18:43 hostname unix: 
DEBUG: pathname_of_command pid 
process_ID lacking privilege number to 
number_of_type_of_access number_resource

The following screen shows the privdebug.log entries from when runpd was run on ping.

Oct 25 18:33:35 tern unix: 
DEBUG: /usr/sbin/ping pid 5138 lacking privilege
36 to create raw socket
Oct 25 18:33:35 tribble unix: 
DEBUG: /usr/sbin/ping pid 5138 lacking privilege
68 to manage transport opts

The privilege numbers appear after the word "privilege." You can look up a privilege number in the /usr/include/sys/tsol/priv_names.h file to find its name. For example, the privilege number 36 is associated with the name net_rawaccess. The numbers following the privilege number and the word "to" are the number of the type of access attempted followed by the number of the resource.

Have the security administrator evaluate whether to give the program the privileges it is missing.

If the privileges should be granted, see "To Give Forced Privileges to a Command" and "Adding or Modifying a Rights Profile" for how to assign privileges.

Turn off privilege debugging: restore the changes you made to the /etc/system file and the /etc/syslog.conf file in Step 3 and Step 5 and reboot the machine.