test

Trusted Solaris Developer's Guide

Security Policy

The laws, rules, and practical guidelines by which the Trusted Solaris environment regulates how sensitive information is protected, managed, and distributed is called security policy. Trusted Solaris applications differ from Solaris applications in that they are subject to mandatory access control (MAC) and cannot run with all the powers of superuser. Solaris applications by contrast are subject to discretionary access control (DAC) only and can run with all the powers of superuser.

The Trusted Solaris environment provides privileges so processes can override mandatory read, write, and search restrictions; discretionary read, write, execute, and search restrictions; and perform special security-related tasks that would normally be reserved for superuser.

Discretionary Access Policy

The Trusted Solaris environment supports discretionary read, write, execute, and search permission using user, group, and other permission bits; and access control lists (ACLs). Controlling access with DAC and ACLs is part of the Solaris operating environment and not described in great detail in this guide, although retrieving ACLs as a file system security attribute is described in Chapter 2, Getting Started and DAC policy is summarized in "Discretionary Access"

Mandatory Access Policy

The Trusted Solaris environment supports mandatory search, read, and write operations. MAC is enforced by comparing the sensitivity label and clearance of a process with the sensitivity label of the object to which the process is seeking access and determining whether the access is allowed or denied according to the MAC policy enforced on the object and the outcome of the comparison.

The outcome states the relationship between the process sensitivity label and object sensitivity label and is described as one dominating the other or equaling the other. The relationships of dominance and equality are covered in Chapter 4, Labels, and summarized here:

The outcome also states the relationship between the process clearance and the object sensitivity label as one of dominance or equality. If the access operation attempts to change the CMW label of the object, the clearance sets the highest level to which the sensitivity label portion can be changed. If the access operation is a write-up (see "Write Access" below), the clearance sets the highest level to which the process may write.

The Trusted Solaris environment supports the following mandatory read and write operations on interactions between unprivileged processes and the objects they access. See "Policy Enforcement" for information on how these operations apply to objects.

Read Access

The Trusted Solaris definition of mandatory read access includes read-equal and read-down:

Write Access

The Trusted Solaris definition of mandatory write access includes write-equal and write-up:

When to Use Privileges

To know if your application can run without privilege, you need to know what tasks use which privileges and when those privileges are needed. The following guidelines are to help you determine what privileges (if any) an application might need.

See Appendix A, Programmer's Reference for information on how to access man pages to obtain information on privileges and privilege descriptions.

Administrative and User Applications

Administrative applications run at the administrative sensitivity labels of ADMIN_HIGH or ADMIN_LOW. At ADMIN_HIGH, the application can read down to any object to which it has discretionary access, and at ADMIN_LOW, the application can write up to any object to which it has discretionary access. An administrator will generally launch an application at ADMIN_HIGH to perform read-down operations, and launch the same application at ADMIN_LOW to perform write-up operations. In these cases, no privileges are needed as long as the application has discretionary access.

See "Initialize Binary Labels and Check Types" in Chapter 5, Label Code Examples for definitions of and information on initializing labels to ADMIN_HIGH and ADMIN_LOW.

Users generally launch an application at a given sensitivity label and access objects at that same sensitivity label. If the user keeps data at another sensitivity label, he or she will usually change the workspace sensitivity label and launch the application at the new sensitivity label. In this case, no privileges are needed as long as the application also has discretionary access.

If a user application is designed to access objects at sensitivity labels different from the sensitivity label at which the application is running, the application might need privilege to complete its tasks if mandatory access is denied.

See "Label Guidelines" in Chapter 4, Labels for guidance on the use of privileges to bypass mandatory access controls or to change a process or object sensitivity label.

Policy Enforcement

In UNIX all input and output is performed through a file interface, which means that file system security policy applies throughout the Trusted Solaris environment. For this reason, file system security policy is described in detail here.

File system security policy is stated in terms of the following:

Security policy for interprocess communications (IPC) is stated in terms of mandatory read and write access checks between the accessing process and the process being accessed. Some IPC mechanisms and X Window System objects use files, and file system security policy as described in this section applies to those operations. Some IPC mechanisms have the read-down and write-up security policy, while other IPC mechanisms have the more restrictive read-equal and write-equal policy. The X Window system has the write-equal and read-down policy. See the following chapters for specific security policy information on these topics:

File System Security Policy

This section describes mandatory and discretionary access checks for the following file system objects:

Discretionary Access

The owner of the process must have discretionary search (execute) access to all directories in the path preceding the final object. Once the final object is reached, access operations can be performed as follows.

Mandatory Access

In addition to passing the DAC checks, mandatory search access is required to all directories in the path preceding the final file. Mandatory search access to a directory is allowed when the process sensitivity label dominates the sensitivity label of all directories in the path. Once the final file is reached, access operations can be performed as follows.

File System Access Privileges

When a discretionary or mandatory access check fails on a file system object, the process can assert privilege to bypass security policy, or raise an error if the task should not be allowed at the current label or for that user.

Discretionary access is enabled as follows:

Mandatory access is enabled as follows:

When Access Checks are Performed

Mandatory and discretionary access checks are performed on the path name at the time a file system object is opened. No further access checks are performed when the file descriptor is used in other system calls, except as follows:

File System Policy Examples

The examples in this section illustrate the kinds of things you need to think about when a process accesses a file system object for read, write, search, and execute operations.

The process accesses /export/home/heartyann/somefile for reading and writing, and /export/home/heartyann/filetoexec for execution. These files are both protected at Confidential. The process sensitivity label is Secret and the process clearance is Top Secret. Confidential is lower than Secret and Secret is lower than Top Secret.

Sensitivity Labels

As shown in the following figure, the path /export/home has a sensitivity label of ADMIN_LOW and the heartyann directory and somefile have a sensitivity label of Confidential.

Figure 1-1 Accessing a File System Object

Graphic

If the process fails a mandatory or discretionary access check, the program needs to assert an error or the proper privilege if the program is intended to run with privilege.

See Chapter 4, Labels in "Label Guidelines" for information on handling sensitivity labels when privileges are used to bypass access controls.

Open the File

The Secret process opens somefile for reading, performs a read operation, and closes the file. The fully adorned pathname is used so somefile in the Confidential /export/home/heartyann single-level directory is accessed.

A fully adorned pathname uses the multilevel directory adornment and specifies precisely which single-level directory is wanted. If a regular pathname was used instead, the Secret single-level directory would be accessed because the process is running at Secret.

See "Adorned Names" for a discussion on fully adorned pathnames. Chapter 7, Multilevel Directories presents interfaces for handling multilevel and single-level directories so fully adorned pathnames are not hardcoded the way they have been for clarity in these examples.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

main()
{
	int filedes, retval;
	ssize_t size;
	char readbuf[1024];
	char *buffer = "Write to File.";
	char *file = "/export/home/.MLD.heartyann/.SLD.1/filetoexec";
	char *argv[10] = {"filetoexec"};

	filedes = open("/export/home/.MLD.heartyann/.SLD.1/somefile", O_RDONLY);
	size = read(filedes, readbuf, 29);
	retval = close(filedes);

Write to the File

The Secret process opens somefile for writing in the Confidential /export/home/heartyann single-level directory, performs a write operation, and closes the file. 

filedes = open("/export/home/.MLD.heartyann/.SLD.1/somefile", O_WRONLY);
size = write(filedes, buffer, 14);
retval = close(filedes);

Execute a File

The Secret process executes an executable file in the Confidential /export/home/heartyann single-level directory. 

retval = execv(file, argv);