Sandboxing Apps

Legato uses sandboxes to provide a security layer between apps running in the same system. Legato sandboxes isolate apps from the rest of the system. This allows both original equipment manufacturer (OEM) and independent software vendor (ISV) apps to coexist safely on the same device without fear of interfering with each other or breaking the rest of the software stack.

Each app has its own unique user ID, group ID, and root directory.

Legato sandboxes use chroot to limit an app's view to its own section of the file system only. Files are bound into the chroot jail using bind mounts. The process then only has access to files and directories under its root directory. Only processes with certain capabilities can find their way outside of their root directory; processes belonging to sandboxed apps run as unprivileged users that don't have those capabilities.

Legato sandboxes use bind mounts to import files into sandboxes (defined using the .adef and .sdef requires section). This works like a file system hard link, except that the link is only stored in RAM and can cross over to different file systems. Bind-mounting avoids copying so the overhead is minimal.

Access control for files visible within the sandbox is done using a combination of standard POSIX discretionary access control (based on user and group permissions) and mandatory access control provided by Linux's SMACK.

A Legato sandboxed app can access services outside its sandbox via inter-process communication (IPC). All available IPC services are advertised by the Service Directory. Apps connect to services through a request to the Service Directory. The Service Directory grants access only if the app has been explicitly bound to a service (using the .adef and .sdef bindings section). When access is granted, the connection to the client is passed to the server and all communication between the client and the server are direct from that point on. SMACK is also used to add another layer of security to the IPC, limiting the passing of IPC socket file descriptors from one app to another

Legato sandboxes also provide resource limitations. Resource limitations place limits on the amount of system resources an app is allowed to consume. Without resource limits, an isolated app can still cause damage by consuming all available resources.

For more details on Sandbox Security:

Section	Description
Sandbox Overview	Overview of Sandbox Security
Sandbox Config Sample	Configuration Sample of adding Sandboxing to an app
Sandboxed App Limits	Sandbox limitations

SMACK

Simplified Mandatory Access Control Kernel (SMACK) provides a simple solution for mandatory access control (MAC). MAC provides the ability for a centralized entity to set access policy for system resources.

The Linux default access control policy is governed by permission bits on system resources at the discretion of the resource owner: discretionary access control (DAC). Policies are set in a distributed way so different system users can set access policy for their own resources.

MAC policies are often used to overcome DAC limitations for systems that require a higher level of security.

SMACK is used to supplement DAC. DAC permissions are checked first; if access is granted, SMACK permissions are then checked. SMACK can only limit access, it can't grant access beyond DAC permissions.

SMACK uses 'labels' on resources (objects in SMACK terminology) and processes (subjects) to determine access. Labels on resources can only be set by a privileged process (the CAP_MAC_OVERRIDE label designates a process as privileged)

SMACK policies are set by the Legato startup scripts, the Legato Installer and the Legato Supervisor.

Section	Description
Implementing SMACK	Overview of SMACK security as implimented in the Framework