Developing, Testing, and Debugging

Development, testing, and debugging should take place on an isolated development system to prevent software bugs and incomplete code from compromising security policy on the main system.

• Remove extra debugging code especially code that provides undocumented features and back doors that bypass security checks.

• Make application data manipulation easy to follow so it can be inspected for security problems by the system administrator before installation.

• Test return codes for all programming interfaces. An unsuccessful call can have unpredictable results. When an unexpected error condition occurs, the application should always terminate.

• Test all functionality by running the application at all sensitivity labels and from all roles at which you expect it to run.

  • If the program is run by a normal user (not by a role), launch it from the command line as a normal user at the labels in the user accreditation range at which it is intended to run.

  • If the program is run by a role, launch it from the command line from the administrative role at one the administrative label at which it is intended to run (ADMIN_HIGH or ADMIN_LOW), or from the user role at the labels in the user accreditation range at which it is intended to run.

• Test all functionality under privilege debugging mode so you know if the application has all the privileges it needs, or if it is attempting to perform privileged tasks that it should not be attempting.

• Know and follow privilege bracketing.

• Know the security implications of using privileges, and make sure the application does not compromise system security by its use of privilege.

• If you are applying the SUNWSpro debugger/dbx/dbxtool to test a privileged application, you must start the debugger first and then attach it to a running process. You cannot start the debugger with the command name as an argument.

Privilege Debugging

Privilege debugging mode is described in Trusted Solaris Administrator's Procedures. This is a summary of the steps for enabling privilege debugging and using runpd(1M) under privilege debugging mode to test an application.

1. Privilege debugging mode allows an application to succeed when it does not have the privileges it needs and tells you which privileges are missing.

2. In the /etc/system file, set the tsol_privs_debug variable to 1. This file is ADMIN_LOW and the owner is root.

3. In the /etc/syslog.conf file, uncomment the kern.debug; local0.debug line. This file is ADMIN_LOW and the owner is sys.

4. Touch the /var/log/privdebug.log file. This file is ADMIN_HIGH and the owner is root.

5. Reboot your system.

6. Assume an administrative role with runpd(1M) in the profile.

7. Use the runpd() command to invoke the executable and find out which privileges, if any, are missing. The following command line invokes the executable file in Zelda's confidential home directory. Information on missing privileges displays at the command line and is logged to the /var/log/privdebug.log file.

phoenix# runpd /export/home/.MLD.Zelda/.SLD.2/executable

runpd terminated with a status of 1

process runpd pid 822 lacking privilege file_mac_search to 
perform special method upon resource VNODE (Jan 29 12:45)

process runpd pid 822 lacking privilege file_mac_read to 
perform read method upon resource VNODE (Jan 29 12:45)

1. Interpret privilege numbers in the /var/log/privdebug.log file. The privilege number appears after the word privilege. Process 822 lacks privilege numbers 11 and 10 which correspond to file_mac_search and file_mac_read.

Jan 29 12:45:39 phoenix unix DEBUG: runpd pid 822 lacking 
privilege 11 to 5 79

Jan 29 12:45:39 phoenix unix DEBUG: runpd pid 822 lacking 
privilege 10 to 2 79

Assigning File Privileges using a Script

How to write privileged scripts to be deployed and used by others in your organization is described in Trusted Solaris Administrator's Procedures. This section briefly explains how to create a script that uses setfpriv(1) to assign forced and allowed privileges to an executable file for testing and debugging an application during application development.

First of all, the user or role you are working in needs a profile with the setfpriv(1) command and file_setpriv privilege assigned to it. The Object Privilege Management profile in the default system has these. To run the script from any shell and have the commands invoked by the script run under the profile shell and inherit your profile privileges, invoke pfsh(1M) at the top of the script as shown in the example below.

The example assigns forced and allowed privileges to executable. The -s -f options set forced privileges on executable, and the -a option sets allowed privileges on executable. This script will quit with the error: executable: not owner unless the file_setpriv privilege is inherited by the commands.

#/bin/pfsh
setfpriv -s -f 
ipc_mac_write,proc_setsl,sys_trans_label -a 
ipc_mac_write,proc_setsl,sys_trans_label executable

When you use a script to put forced and allowed privileges on an executable file, keep the following points in mind:

• If you remove a privilege from the allowed set specified in the script, you must also remove it from the forced set. If you remove it from the allowed set only, you will see the error: executable: Invalid argument when you run the script.

• If your program inherits privileges, launch it from the command line in the profile shell with the privileges to be inherited.

  • The allowed set of the executable file must have the privileges to be inherited.

  • If your program is going to only inherit privileges, the forced set of the executable file should be empty.

  • If your program takes a different action when a privilege is forced from when it is inherited, launch the program with the privilege in the forced and allowed set, and launch the program again with the privilege in the allowed set from a profile shell that has the privilege to be inherited.

Always test the program at all labels at which it is intended to run.