This appendix explains where to find information about developing, testing, and releasing label-aware applications to an environment that uses the Solaris Trusted Extensions software.
This appendix covers the following topics:
Most Trusted Extensions header files are located in the /usr/include/tsol directory and in the /usr/include/sys/tsol directory. The locations of other header files are shown in the following table.
Header File and Its Location |
Category of Interface |
---|---|
/usr/openwin/include/X11/extensions/Xtsol.h |
X Window System |
/usr/include/libtsnet.h |
Trusted network library |
/usr/include/bsm/libbsm.h |
Audit library |
Many of the Trusted Extensions interface names and data structure names use the following short abbreviations. Knowing the abbreviations of these names will help you recognize the purpose of an interface or structure.
Table A–1 Name Abbreviations Used by Trusted Extensions APIs
Abbreviation |
Name |
---|---|
attr |
Attribute |
b |
Binary |
clear |
Clearance |
ent |
Entry |
f |
File |
fs |
File system |
h |
Hexadecimal |
l |
Level, label, or symbolic link |
prop |
Properties |
r |
Re-entrant |
res |
Resource |
s |
String |
sec |
Security |
sl |
Sensitivity label |
tp |
Trusted Path |
tsol |
Trusted Extensions |
xtsol |
Trusted X11 Server |
You must develop, test, and debug an application on an isolated development system to prevent software bugs and incomplete code from compromising the security policy on the main system.
Follow these guidelines:
Remove extra debugging code, especially code that provides undocumented features and code that bypasses security checks.
Make application data manipulation easy to follow so that the manipulation can be inspected for security problems by an 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 must always terminate.
Test all functionality by running the application at all sensitivity labels and from all roles that you expect will run the application.
If the program is run by an ordinary user and not by a role, start the program from the command line at the labels where the program is intended to run.
If the program is run by a role, start the program from the command line in the global zone or from the user role at the labels where the program is intended to run.
Test all functionality under privilege debugging mode so that you know whether the application has all the privileges it needs. This type of testing also determines whether the application is attempting to perform privileged tasks that it should not be performing.
Know the security implications of using privileges. Ensure that the application does not compromise system security by its use of privileges.
Know and follow good privilege bracketing practices.
If you use the SUNWspro debugger or the dbx command to test a privileged application, start the debugger before you attach it to a running process. You cannot start the debugger with the command name as an argument.
You submit a fully tested and debugged application to the system administrator for application integration. The application can be submitted as a software package. If the application uses privileges, the system administrator must evaluate the application source code and the security information that you supply. This evaluation verifies that your use of privileges does not compromise system security.
Notify the system administrator of new auditing events, audit classes, or X Window System properties that your application uses. The system administrator must place these items into the correct files. For more information, see Chapter 6, Trusted X Window System.
To create a software package, see the Application Packaging Developer’s Guide. To debug package installation issues, see Chapter 14, Troubleshooting Software Problems (Overview), in System Administration Guide: Advanced Administration.