Configuring Sandboxes for Project Isolation
Sandboxes are isolated environments where authorized users can run an application that is protected from other processes on the system. Sandboxes provide security isolation to files, processes, and shared memory; and provide resource isolation to file allocation, memory allocation, and the CPU.
Sandboxes are lightweight. In Oracle Solaris, they are implemented by using labels. Sandboxes isolate applications by restricting the applications' process attributes, such as their clearances and privileges. Regular users can create temporary sandboxes by using the sandbox command. Administrators can create persistent, named sandboxes with specific security attributes by using the sandboxadm command. Authorized users access their named sandboxes by using the sandbox command.
Named sandboxes have hierarchical and disjoint properties that correspond to their clearances. For example, each parent sandbox can have up to 4096 child sandboxes, each of which is isolated from the others. Up to eight disjoint parent sandboxes can be created on a system. In addition, you can create a top-level parent sandbox which dominates every other sandbox. Named sandboxes also have an associated user ID, primary and supplementary group IDs, and projects. You as the administrator must be assigned the Sandbox Management rights profile to create and configure named sandboxes.
In the following sample hierarchy, CDBall-SandboxAll is the top-level parent sandbox. It has two disjoint child sandboxes, CDB1-SandboxAll and CDB2-SandboxAll. The ellipses indicate that the top-level parent can have more children. Each child sandbox has named children and can have more, up to 4096. As you traverse the tree from the top-level parent to the child sandboxes, process privileges and clearances are reduced. The child sandboxes are for operations that require fewer privileges than are granted to the top level. Each sandbox has a unique project name associated with it and can have resources assigned to it.
Figure 4 Sample Sandbox Hierarchy
You can use the sandbox command to enter either temporary or named sandboxes. Although this command is unprivileged, the security attributes of the invoking process must be consistent with the security attributes of the target sandbox. For example, the current process clearance must dominate the target sandbox clearance. Before you enter a sandbox, you should set the current working directory to a directory whose label is dominated by the target sandbox. For more information, see the sandbox(1) man page.
To enter a named parent sandbox, the current effective UID must match the UID that is assigned to the target sandbox. Before entering a named child sandbox, the caller must previously have entered its parent sandbox. After you enter a sandbox, the process project is set to that of the sandbox and the clearance is set to the clearance of the sandbox. For more information, see the sandbox_create(3SANDBOX) man page.
You use the sandboxadm command to create named sandboxes. This command works with a special version of the encodings file, "Sandbox Labels v1.0". For information about installing and using this file, see the sandboxadm(8) man page.
When you use the sandboxadm command to create named sandboxes, the relationships you specify enable the command to automatically assign the appropriate clearance to the sandbox. Parent sandboxes must be created prior to creating any of their child sandboxes. If a parent sandbox is specified, then the new sandbox is assigned a clearance which is dominated by the parent sandbox, and disjoint from every other sandbox except the top-level sandbox. Although each child sandbox must have a unique username, multiple parent sandboxes can be owned by the same user. In that case, the clearance of that user is automatically set to a clearance that dominates all of the sandboxes that the user owns.
Each named sandbox also has a corresponding project of the same name which is automatically applied when the sandbox is entered. The user associated with the named sandbox is automatically assigned to that project. Resource management attributes can be assigned to sandboxes through the projmod command.
Processes within a child sandbox can not observe any processes outside of their sandbox. Processes in parent sandboxes can only observe processes in their own sandbox and those of their children. Similarly, file access is restricted so that only files and directories that are dominated by the sandbox clearance are visible. Shared memory that has been labeled by the shmctl system call can be also be isolated to individual sandboxes.
Preparing for Persistent Sandboxes
Named sandboxes provide persistent sandboxes that authorized users can log in to when performing operations that do not require the level of privilege that these users are assigned by default. In a labeled environment that is not designed for sandboxes, authorized users can use the sandbox command to create sandboxes to run applications or processes at a lower clearance, but these sandboxes do not persist after the session is closed.
Persistent, named sandboxes require you to configure a special label encodings file. Then, you or the user whom you authorize to access a sandbox must create directories on a file system at the label of the sandbox. Only one user can access a sandbox – it is an isolated environment for that user. For information about creating labeled directories and file systems, see Chapter 3, Labeling Files for Data Loss Protection in Securing Files and Verifying File Integrity in Oracle Solaris 11.4.