Privileges and Authorizations

Privileges let a process perform security-related tasks normally prohibited by the system security policy. Authorizations let a user perform privileged tasks not allowed to all users. Every authorization maps to a privileged task. Always check a user's authorizations before allowing a privileged task to take place.

The development, testing, and debugging of privileged applications should always be on an isolated development machine to prevent bugs and incomplete code from compromising security policy on the main system.

Privileges distribute security-related powers so a process has enough power to perform a task and no more. Likewise, authorizations distribute security-related powers so each user or role has enough power to perform a task and no more.

The system administrator assigns authorizations to users and roles through an execution profile. The chkauth(3TSOL) routine accepts a valid user name and authorization as parameters and returns true if the authorization is assigned to that user. During development, privileges can be assigned to the executable file and/or inherited from the user's or role's executable profile at run time.

To know if a program performs tasks that require privilege and user authorization checks, ask these questions:

• Does the task require privilege?

  • Information on privileges for system calls is on the Intro(2) man page and the man page for the particular system call.

  • Information on privileges for library routines is on the man page for the library routine or the man page for the underlying system call if there is an underlying system call. Check the See Also section of the library routine man page for a list of system calls where you can find privilege information if there is no information on the library routine man page.

  • The priv_desc(4) man page provides a list of Trusted Solaris privileges and a description of the tasks they enable.

  • Refer to Chapter 3, Privileges for information to help you decide if the privileges should be assigned to the file, inherited, or both.

  • Use privilege debugging mode as described in Trusted Solaris Administrator's Procedures or "Privilege Debugging" in Appendix A, Programmer's Reference" to find out what privileges an application needs.

• Does the task have an authorization? - The Trusted Solaris authorizations and their descriptions are in /etc/security/auth_attr.

This example checks the process permitted set for the file_downgrade_sl privilege, and the user authorization solaris.label.file.downgrade for user ID zelda before performing a task that involves downgrading the sensitivity label on a file. If the privilege is in the permitted set and if zelda has the authorization, the code turns the file_downgrade_sl privilege on in the effective set (makes the privilege effective) and performs the task. When the task completes, file_downgrade_sl is turned off (is no longer effective).

The example compiles with the following libraries:

-lsecdb -lnsl -lcmd -ltsol

The permitted set contains the privileges the process can potentially use during execution, and the effective set contains the privileges the process is actually using at a given time. Turning effective privileges on and off is called privilege bracketing and is discussed in Chapter 3, Privileges.

#include <tsol/priv.h>
#include <tsol/auth.h>

main()
{
	char *zelda = "zelda";
	priv_set_t priv_set;

/* Retrieve the permitted privilege set */
	getppriv(PRIV_PERMITTED, &priv_set);

	if(PRIV_ISASSERT(&priv_set, PRIV_FILE_DOWNGRADE_SL) &&
		chkauthattr(solaris.label.file.downgrade, zelda)) {
		set_effective_priv(PRIV_ON, 1, PRIV_FILE_DOWNGRADE_SL);
		/* Downgrade sensitivity label on file*/
		set_effective_priv(PRIV_OFF, 1, PRIV_FILE_DOWNGRADE_SL);
	}
	else {/* Raise Errors */}
}