sandboxing - isolated execution environments
Sandboxes are uniquely named sets of process attributes that can be used to specify security and resource isolation requirements. Each sandbox specification consists of a project name, a label, and a set of user attributes.
A set of resource management properties whose project name is the same as the sandbox name, are associated with the sandbox. For more information about the available properties, see resource-controls(7) man page. These resource controls are applied to all processes executing within a sandbox.
Each sandbox has a unique label which specifies how it is hierarchically related to all other sandboxes. For more information, see the labels(7) man page. Processes executed in a sandbox must have a clearance that dominates the sandbox's label. For more information about the description of process labeling, see the clearance(7) man page. Clearances and labels consist of a classification name and one or more compartment names. The names are defined in a label_encodings file which is used by the SMF service:
labeld:clearance
For more information, see the label_encodings(5) man page.
The sandboxing functionality requires the values for classification and compartments are assigned in a disjoint manner. A particular encodings convention, called "Sandbox Labels v1.0" is used. For convenience and consistency, a conforming label encodings file can be generated using the init subcommand of sandbox(1). It provides options to specify the total number of classifications and compartments, as well as their prefixes. For uniqueness, these prefixes are appended with integer values starting with 1. The maximum numbers for classification and compartment names are eight and 4096. The default prefixes are Class and Sandbox. The classification name Public is reserved for the minimum label, which is also the default clearance.
The bit values for these numbered classifications and compartments are disjoint. The suffix "All" is used to specify parent-child hierarchies of classifications or compartments. For example, a sandbox with the label Class1 SandboxAll, is the parent of all sandboxes that share the Class1 classification. Its label is said to dominate the label of its children. All child sandboxes are disjoint from other children, and all parent sandboxes are disjoint from other parents. If the maximum values are used, each of the eight parent sandboxes can have 4096 children, for a total of 32,776 sandboxes. Processes in a sandbox can only access other processes, files, and shared memory segments if their clearance dominates the label of the target object. The special process clearance ClassAll SandboxAll dominates every sandbox label.
When constructing clearances, the Sandbox compartment names are mutually exclusive so they cannot be combined, except by using the special compartment SandboxAll. Although classification names like Class1 and Class2 are disjoint and cannot be combined in a sandbox label, they can be combined in a user clearance. For example, a user with the clearance:
Class2 Class1 SandboxAll
can be the administrator for the two parent sandboxes with the labels:
Class1 SandboxAll Class2 SandboxAll
A process with appropriate process credentials can enter a sandbox without authentication or the use of privilege either by using the sandbox_enter or, by using the sandbox command. The following security policy is enforced:
If the uid of the process is equal to the uid of the user associated with the sandbox, a parent sandbox can be entered, and the process clearance dominates the sandbox's label. A root process running at ADMIN_HIGH is also permitted to enter a parent sandbox. Upon entry the process clearance is set to the label of the sandbox, the uid, and project are set to the sandbox. The primary and supplementary groups associated with the user are also set in the process.
When a process is running in its parent's sandbox, a child sandbox can be entered. The process project is set to that of the child sandbox. The clearance is reduced by replacing the SandboxAll compartment with the uniquely numbered Sandbox compartment associated with the child.
When entering a child sandbox the caller has the option to enter temporarily or permanently. When the temporary option is specified, the uid of the parent sandbox is preserved. If additional (non-sandbox) compartments have been assigned to the parent sandbox they may optionally be preserved in the new process clearance. The caller may subsequently revert to the parent sandbox by using the sandbox_exit(3SANDBOX) function, which restores the process attributes associated with the parent, or the caller may call sandbox_enter(3SANDBOX) function again, this time specifying the permanent option.
If the permanent option is selected, the caller may also specify that its uid and and home directory should be set to those of the child sandbox. If the uid is changed the primary and supplementary groups associated with the user are also set in the process.
The parent and child sandboxes can also be entered using PAM services like, ssh(1). This is possible, if the user has been assigned attributes like, uid, clearance, and project, corresponding to a sandbox. This is similar to calling sandbox_enter(3SANDBOX) function, but the user must first be authenticated. In addition the user's audit ID and audit mask are set, and the operation is auditable.
See attributes(7) for descriptions of the following attributes:
|
plabel(1), sandbox(1), getlabel(2), libtsol(3LIB), setproject(3PROJECT), sandbox_create(3SANDBOX), label_to_str(3TSOL), setclearance(3TSOL), setflabel(3TSOL), str_to_label(3TSOL), label_encodings(5), attributes(7), clearance(7), labels(7), resource-controls(7), projmod(8), sandboxadm(8)
Support for sandboxing was added in Oracle Solaris 11.4.0.