Oracle Solaris 11 | Tuesday, January 30, 2018

Application Sandboxing in Oracle Solaris 11.4

By: Darren Moffat | Senior Software Architect

Portions Contributed by: Glenn Faden

Oracle Solaris Zones provide a robust security boundary around all processes running inside of them. Non-global (aka native) Zones were designed to provide Operating System level virtualisation so they present a complete user space isolation with separate file system namespaces and IP stack, etc while running on a shared kernel. Sometimes it is desirable to wrap an additional security boundary around an application to reduce the risk of it leaking data or executing external tools if it were to be misused. Application Sandboxing provides that lighter weight capability, and it can be used to provide containment even for unprivileged applications.

In March of 2013, Glenn Faden wrote a blog entitled Application Containment via Sandboxing. That prototype led to the development of the new sandboxing(7) infrastructure in Oracle Solaris 11.4. Application Sandboxes are a new security mechanism used to provide additional separation between running programs, with the goal of reducing the risk of unauthorised access, read and write, of user/application data. Sandboxes isolate applications by restricting the applications’ process attributes, such as their clearances and privileges. Sandboxes can be used within global and non-global zones.

A new unprivileged command, sandbox(1) provides various options for entering restricted environments to run applications in an isolated environment. It supports two use cases.

sandbox [-n] -l [clearance] [command] 

sandbox -s sandboxname [command]

The first use case is similar to the original sandboxing prototype in that the user applies specific attributes to customize the sandbox. The -n option is still used to prevent all network access by removing the basic privilege net_access. To restrict the execution to programs under /usr, an extended policy is applied to the privilege proc_exec. The prototype applied extended policies to the basic privileges file_read and file_write to achieve an isolated environment. In the new implementation, file access is restricted by reducing the process clearance. By default, the clearance is set to the system minimum label, Admin_Low, but the -l option can be used to specify any clearance that is dominated by the current process clearance. The current user and group IDs are preserved, but processes inside the sandbox run with a lower clearance, and cannot access the user's processes or files or files that are outside of the sandbox. A subdirectory should be created and assigned a label matching the sandbox clearance prior to entering a sandbox. The sandbox command should be executed from that directory..

In the second use case, the attributes of the sandbox are specified administratively. Administrators with the Sandbox Management rights profile can create persistent, uniquely named sandboxes with specific security attributes using the create subcommand of sandboxadm(8). Named sandboxes have parent and child relationships that are implemented using hierarchical and disjoint clearances. Sandbox clearances are assigned automatically so that the clearances of all parent sandboxes are disjoint from each other, but dominate their respective child sandboxes.

The clearance of each child sandbox is disjoint with respect to every other child sandbox. The default sandboxing configuration supports the creation of up to four disjoint parent sandboxes, each of which may have up to 100 child sandboxes. These limits can be raised using the init option of sandboxadm(8). In addition, a top-level parent sandbox can be created which dominates every other sandbox. The other process attributes of named sandboxes include a unique user ID, optional primary and secondary groups, and a unique project for resource management. The unique sandbox name is also used to identify its corresponding project. The create subcommand also creates a properly labeled home directory for each sandbox. When entering a named sandbox, its associated directory is automatically set as the current working directory.

Access to named sandboxes is restricted by user ID and clearance. 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. 

To enter a parent sandbox, the user ID of the calling process must equal the user ID that has been assigned to the sandbox, or the process must assert the proc_setid privilege. In addition the clearance of the calling process must dominate the clearance assigned to the sandbox. Entry into a child sandbox is restricted to processes that are already running within its parent sandbox. Using sandbox(1) or the corresponding sandbox_enter(3SANDBOX) API does not require a password. However, sandbox accounts may be assigned passwords and/or ssh keys to support local logins or remote access. Upon successful authentication, the sandbox is entered automatically.

Now lets look at an example, running an editor in an application sandbox:

~alice:$ cd playground
~alice/playground:$ sandbox vim

The credentials of the resulting process look like this:


~alice/playground:$ ppriv 103889
103889: vim
flags = PRIV_XPOLICY
     Extended policies:
             {proc_exec}:/export/home/alice/playground
             {proc_exec}:/usr/*
     E: basic,!net_access,!proc_exec,!proc_info,!proc_session
     I: basic,!net_access,!proc_exec,!proc_info,!proc_session
     P: basic,!net_access,!proc_exec,!proc_info,!proc_session
     L: all
~alice/playground:$ plabel $$
103889: ADMIN_LOW

From this we can see that the application (vim) has no network access and we have removed some of the basic privileges that would normally allow it to see and signal other processes on the system.  It can also only execute new processes from /usr or the directory we entered.

The following diagram provides an architectural overview of Oracle Solaris sandboxing, very few people need to understand this but it shows how it fits into the existing Oracle Solaris security architecture:

As you can see from the brief description above the Application Sandboxing functionality is built by using multiple pre-existing Solaris security and resource manamagent features to provide a simple interface to containing applications.

Join the discussion

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha
 

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services