Sandboxes - Legato Docs

Also see Sandbox Overview and Use Sandboxes.

Legato uses sandboxes to provide a security layer against untrusted apps running in the same system. Legato sandboxes isolate apps from the rest of the system. This allows both original equipment manufacturers (OEM) and independent software vendors (ISV) components to safely coexist on the same device without fear of interfering or breaking the stack.

Access control for files is done using the underlying POSIX access control mechanisms, based on users, permissions, and SMACK labels.

All sandboxes are created in RAM, which provides the benefit of automatically removing all sandboxes during system shutdown. Legato sandboxes use bind mounts to import files into sandboxes (defined using the .adef and .sdef requires section). Bind-mounted files are updated when the file is updated. Bind-mounted files aren't copied so memory requirements are minimal.

A Legato sandboxed app can access services outside its sandbox. All available 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).

Legato sandboxes use chroot to limit an app's view to its own file system only. Each app has its own unique user ID, group ID, and root directory. Files are bound into the chroot jail using bind mounts that change a process's root directory to a specified location. 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.

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.