Trusted Solaris Administrator's Procedures

Managing Software (Tasks)

To Mount a CD-ROM for Adding a Package

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

Allocate the CD-ROM device.

Use the Allocate Device option from the Trusted Path menu or launch the Device Allocation Manager action from the Tools subpanel in the Front Panel.

Double-click the name of the CD-ROM device in the list of Available Devices to transfer it to the list of Allocated Devices. Click OK to the ADMIN_LOW label.

Insert the CD-ROM at the specified label into the drive and click the OK button.

Click Yes to mount the CD.

Press return when prompted to close the window.

Deallocate the device when finished.

To Give Forced Privileges to a Command

An executable file with forced privileges runs with those privileges when invoked in a profile shell by any user or role.

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

A file's owner or a user with the Act as File Owner authorization can also add privileges to an executable at a label within the user or role's accreditation range.

Navigate to the file's directory, and make sure the file is executable.

If the file is not an executable and it should be, change permissions to make it executable, as in:
$ chmod 755 filename

Give the command allowed privileges equal to the forced privileges you plan to assign.

If you are using the File Manager Permissions dialog box, click the Allowed button, assign Allowed Privileges, and then click the Forced button to assign the Forced Privileges.

The following example shows using the setfpriv(1) command to set file_dac_read and file_dac_write as allowed and forced privileges.
$ setfpriv -s -f file_dac_read,file_dac_write \ -a file_dac_read,file_dac_write test.priv.file

To Create a New File Edit Action

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

Launch the Admin Editor action to open the /usr/dt/appconfig/types/C/TSOLadmin.dt file for editing.

See "To Log In and Assume a Role", and "To Edit a Local File", if needed.

Copy and paste the definition for one of the existing actions in the TSOLadmin.dt file.

The example in this procedure modifies a copy of the Vfstab action.

ACTION Vfstab
{
        LABEL        Set Mount Points
        ICON         Dtpenpd
        TYPE         COMMAND
        WINDOW_TYPE  NO_STDIO
        EXEC_STRING  /usr/dt/bin/trusted_edit /etc/vfstab
        DESCRIPTION  Specify the file system mount points
}

Modify the copied action's definitions.
1. Change the ACTION name.
  
  This example creates a new action to edit the /etc/system file to modify Trusted Solaris kernel switch settings.
  ACTION EditSystemFile {
2. Change the LABEL.
  LABEL Edit System File
3. Change the ICON, if you have created a new icon or want to use another existing one from /usr/dt/appconfig/icons/C.
  ICON Dtpenpd
4. Change the file name in the EXEC_STRING.
  EXEC_STRING /usr/dt/bin/trusted_edit /etc/system
5. Change the text in the DESCRIPTION.
  DESCRIPTION Modify system file }

Save and close the TSOLadmin.dt file.
:wq

Copy and rename the Vfstab action file.
1. Go to /usr/dt/appconfig/appmanager/C/System_Admin.
2. Clone the Vfstab file and rename it to the name of the new action.
  
  For example, rename Vfstab to EditSystemFile.
3. Make the action file executable.
  
  Select the Permissions option on the File Manager's File menu and set the permissions to executable for owner, group, and other, or enter the following on the command line:
  $ chmod 777 EditSystemFile

In the System Administrator role, copy the modified TSOLadmin.dt and action files to every host in the domain.

Since actions are not administered through the name service, some other means of distribution must be used, such as rdist(1) or sneakernet (copying the files to a floppy and carrying it around to install the files on each host).

In the Security Administrator role, bring up the Solaris Management Console, choosing the appropriate name service scope.

To make the action available only to one host, choose the Files scope on the host.

Click Users and provide a password when prompted.

Double-click the Rights tool, then double-click either the Information Security profile or the Object Access Management profile.

The Properties dialog box for the Right displays.
1. If the action edits a security-relevant file, such as the /etc/system file, open the Information Security profile.
2. If the action edits an administrative file that would normally be modified by a UNIX system administrator and that does not contain labels or other security attributes, such as the group file, open the System Management profile.

Click Actions, then System_Admin in the Actions Denied column.

The new action should be listed. Refer to the online help for assistance.

Add the action to the rights profile, and assign to the action the same privileges that are assigned to the Set Mount Points action: file_dac_read, file_dac_write, proc_audit_appl, proc_audit_tcb.

To make the action usable, log out and log in again.

To Add Actions Outside of the System_Admin Folder

Adding actions can be done as described in the Solaris Common Desktop Environment: Advanced User's and System Administrator's Guide, within Trusted Solaris MAC constraints.

As a user or role, create the action by using the CreateAction action, or manually.

Assume the Security Administrator role, and label the action ADMIN_LOW.

Place it in the /etc/dt/appconfig/types/C directory so that CDE makes it available.

Note -
Added actions are software. Their trustworthiness must be checked before they are made generally available. See "Testing New Software for Security".

To Make New Actions Available to the Rights Tool

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

Remove the /usr/dt/appconfig/smc/C/actions file on the SMC server.
$ rm /usr/dt/appconfig/smc/C/actions

Log out and log into the SMC server using the CDE login screen.

CDE regenerates the removed file, and populates it with all actions that it finds.

To Write a Profile Shell Script

Note -

When adding a profile shell script that runs commands with inherited privilege, the Security Administrator role needs to update an appropriate rights profile with a list of each of the commands that run within the shell script and to assign the commands any privileges they need. If a new shell script needs to be used by a role, all the commands that need security attributes must be added to the Custom role_name Profile or other profile that applies to the role, along with the name of the script itself.

Anyone with a text editor can write the shell script.

Start the script with /bin/pfsh (or any other profile shell) on the first line.
#!/bin/pfsh

Determine which commands need privileges and which privileges are needed.

In the example, /usr/lib/fs/nfs/nfsfind is a cron job owned by root that needs privileges in order to run successfully at ADMIN_HIGH. The tfind command needs the file_dac_search and file_dac_read privileges and the rm command needs the file_dac_search, file_dac_write, file_dac_read, and file_mac_write privileges. See "To Find Out Which Privileges a Program Needs", if needed.

#!/bin/pfsh
# Copyright (c) 1993, 1997, 1998, 1999 by Sun Microsystems, Inc.
#ident  "@(#)nfsfind.sh 1.5     97/05/21 SMI; TSOL 2.x"
#
# Check shared NFS filesystems for .nfs* files that
# are more than a week old.
# 
# These files are created by NFS clients when an open file
# is removed. To preserve some semblance of UNIX semantics
# the client renames the file to a unique name so that the
# file appears to have been removed from the directory, but
# is still usable by the process that has the file open.
if [ ! -s /etc/dfs/sharetab ]; then exit ; fi
 for dir in `awk '$3 == "nfs" {print $1}' /etc/dfs/sharetab`
do 
    tfind $dir -M -name .nfs\* -mtime +7 -mount -exec rm -f {} \;
done

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

Use the Rights tool to update an appropriate profile to list the script, each of the commands that need to run within the shell script and to assign the commands the privileges they need.

See "To Launch the Solaris Management Console", if needed.

To continue with the example, to enable the System Administrator role to run the example cron script with the needed privileges, the Security Administrator uses the Rights tool to update the Custom Admin Role and makes sure it is assigned to the System Administrator role. The rights profile is modified to include the /usr/lib/fs/nfs/nfsfind script, the tfind command with the file_dac_search and file_dac_read privileges and the rm command with the file_dac_search, file_dac_write, file_dac_read, and file_mac_write privileges.

Caution -
When you add commands to a profile and give them privileges or other security attributes, the commands execute with those attributes, not only in the profile shell script but whenever they are invoked in any profile shell, as long as the profile is in effect for the invoking account. The order of profiles is also important: the profile shell executes a command or action with whatever security attributes are specified in the first profile in the account's list of profiles. For example, if tfind is in the Custom Root Profile with privileges, and the Custom Root Profile is the first profile in which tfind is found, then tfind will inherit the privileges specified in the Custom Root Profile when the root role executes tfind on the command line in a profile shell.

To Write a Standard Shell Script that Runs Privileged Commands

Note -

You can create a standard shell script to run its commands with privileges by adding the script to a rights profile and specifying the script to run with all the privileges that are needed by the script's commands. The script then inherits privileges when invoked in a profile shell, when an account has a rights profile containing the script.

Start the script with any standard shell (not a profile shell) on the first line.
#!/bin/csh

In the PrivDebug or the Security Administrator role, determine what privileges are needed by what commands in script.

See "To Find Out Which Privileges a Program Needs", if needed. The example, called autosetpriv, would enable the Security Administrator to assign a defined set of forced and allowed privileges to a file called executable. The setfpriv command in this script needs the file_setpriv privilege.

Note -
This shell script is just an example. A normal shell script accepts the privileges and the filename as arguments and does error checking.
#!/bin/csh setfpriv -s -f ipc_mac_write,proc_setsl,sys_trans_label -a ipc_mac_write,proc_setsl,sys_trans_label executable

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

Use the Rights tool to update an appropriate profile to list the script, each of the commands that need to run within the shell script and to assign to the commands the required privileges.

See "Adding or Modifying a Rights Profile", if needed.

To enable the script called autosetpriv to run with the file_setpriv privilege needed by the setfpriv command, the Security Administrator role would use the Rights tool to update the Custom Secadmin Role (which is assigned to the Security Administrator role by default) to include the autosetpriv script and assign to autosetpriv the file_setpriv privileges.

Test, debug, and execute the shell script as desired in the profile shell.
$ autosetpriv

To Save and Restore Privileges When Editing a File

Assume the Security Administrator role and use the getfpriv command to list the privileges on the executable file and save the output.

The following example directs the output into a temporary file.
$ getfpriv executable_file > tempfile

After editing the executable file, use the File Manager to make the file executable again (if needed) and then restore the privileges listed in the temporary file.

The following example uses the setfpriv(1) command to set the privileges stored in the tempfile created in Step 1.
$ setfpriv -s -f `cat tempfile` program_pathname

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.

To Make a Library Directory Trusted

The following procedure describes how to determine which libraries should be trusted, and then describes how to add them to the trusted library directories list.

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

Remove any forced privileges assigned to the program.

If the program does not have forced privileges, then you do not need to do the following substeps or Step 4.
1. Check the command for forced privileges.
  
  The following example gets the list of privileges and saves them in a file. The file can be used to reset the privileges, if any, after the ldd(1) command is run.
  $ getfpriv -s -f program_name > filename
2. Remove the privileges from the program.
  $ setfpriv -s -f none program_name

Use theldd command to find out which library directories the application program is using.
$ ldd program_name
Note -
The program that is using the shared libraries may be imbedded in a script, so make sure you are running ldd on the actual program that needs the libraries.

If you removed forced privileges from the program in Step 2, add the privileges back to the program.

The following example uses setfpriv to set the privileges stored in filename in Step a.
$ setfpriv -s -f `cat filename` program_name

Use the Rights tool to add the crle command to the Custom Secadmin Profile with a real UID of 0, and a label and clearance of ADMIN_LOW.

See the crle(1) man page for more information.

Use the crle command to add the library directories from Step 3 to the list of trusted library directories.
$ crle -u -s [directory_1[: . . . :directory_N]

To regenerate the list of trusted directories at every reboot, add the crle command to a boot-time script.

Use the Admin Editor to create or modify a script in the /etc/init.d directory.

If a privileged application already has a script, modify the existing script. Otherwise, create a new script.

Caution -
Do not modify any default Trusted Solaris scripts. Modify only scripts that are installed with new applications that need privileges.

The following is an example of executing the crle command in a script:
crle -u -s directory_1[: . . . :directory_N]

Make a hard link from the script in the /etc/init.d directory.

Use the S prefix in the target file's name for starting the script. Use the proper two-digit number in the target file's name to determine the order in which the script is executed during the run level. See the README in /etc/init.d and /etc/rc2.d, if needed.

In the following example, the name of the new script in /etc/init.d is new_script, which is linked to /etc/rc2.d/S87new_script.
$ cd /etc/rc2.d $ ln /etc/init.d/new_script S87new_script

To Add Commands to the `/etc/inittab` File

Assume the Security Administrator role and use the Admin Editor action at ADMIN_LOW to edit the file /etc/inittab.

The following example adds /usr/local/bin/mysite to the file.
lo:234:respawn:/usr/local/bin/mysite

Save and quit the file.
:wq

Use the Rights tool in the Files scope to add the script /usr/local/bin/mysite to the boot rights profile with a real UID of 0.

To Run `rc` Scripts With Security Attributes

Note -

To add security to rc scripts, create a new profile and use the setprof command to refer to the new profile in a new sysh(1M) script, as described in this procedure.

Assume the Security Administrator role and use the Admin Editor action at ADMIN_LOW to create a new sysh script in /etc/init.d.

See the sysh(1M) man page and "System Shell". The first line of the script should read as follows:
#!/bin/sysh

On the second line of the script, type in the setprof option to identify the name of a rights profile.
setprof new_profile_name

Save and quit the file.
:wq

In the /etc/init.d directory, make a hard link from the new script to the desired /etc/rcn.d directories.
1. For each run level at which the command should be started or stopped, go to the appropriate /etc/rcn.d directory and create a hard link from a properly-named target file to the /etc/init.d directory.
2. Use the proper prefix in the target file's name for either starting (S) or stopping (K).
3. Use the proper numbers in the target file's name to help determine the order in which the script is executed during the run level.
  
  In the following example, the name of the new script in /etc/init.d is new_script, which is linked to /etc/rc2.d/S89new_script and /etc/rc2.d/K8new_script.
  $ pwd /etc/init.d $ ln new_script /etc/rc2.d/S89new_script $ ln new_script /etc/rc2.d/K89new_script

Use the Rights tool with the Files scope to create a new rights profile.

Add the command and any desired security attributes.

Reboot to effect the change.

To Add Services to the `inetd.conf` File

Assume the Security Administrator role and use the Admin Editor action in an ADMIN_LOW workspace to open the /etc/inet/inetd.conf file for editing.

For example, the following line adds a service in /usr/local/bin named newservice with the CLIENT keyword in the UID field so that the service executes with the UID and GID(s) of the CLIENT. In the flags field, the trusted keyword causes the service to run with the trusted path attribute, and the setaudit keyword causes the service to run with the client's audit characteristics:
myport stream tcp6 nowait,trusted,setaudit CLIENT /usr/local/bin/newservice

Save and quit the file.
:wq

If the service needs to run with privileges or a restricted label range, use the Rights tool to add the service to the inetd rights profile along with any desired security attributes.

To Install a Java Jar File

The security administrator must verify that the source of the Java program is trustworthy, that the method of delivery is secure, and that the program can run in a trustworthy manner. To limit the security risk, the system administrator can download the software to a single label within the users' accreditation range, where the security administrator can test it at that label. The administrator can then downgrade the label to ADMIN_LOW, and install it on an application server to make it available to all users.

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

Download the Java jar file to the /tmp directory.

For example, if you are selecting software from the http://www.sunfreeware.com, download the link that is described with "Web Start Wizard form of application.

Open a File Manager to the /tmp directory.

The Software Installation profile includes the Open action for Java code.

Double-click the downloaded file.

Answer the questions in the dialog boxes to install the software.

Read the installation log.

Managing Software (Tasks)

To Mount a CD-ROM for Adding a Package

To Give Forced Privileges to a Command

To Create a New File Edit Action

To Add Actions Outside of the System_Admin Folder

To Make New Actions Available to the Rights Tool

To Write a Profile Shell Script

To Write a Standard Shell Script that Runs Privileged Commands

To Save and Restore Privileges When Editing a File

To Find Out Which Privileges a Program Needs

To Make a Library Directory Trusted

To Add Commands to the /etc/inittab File

To Run rc Scripts With Security Attributes

To Add Services to the inetd.conf File

To Install a Java Jar File

To Add Commands to the `/etc/inittab` File

To Run `rc` Scripts With Security Attributes

To Add Services to the `inetd.conf` File