A Study of Security Isolation Techniques

Abstract

Security isolation is a foundation of computing systems that enables resilience to different forms of attacks. This article seeks to understand existing security isolation techniques by systematically classifying different approaches and analyzing their properties. We provide a hierarchical classification structure for grouping different security isolation techniques. At the top level, we consider two principal aspects: mechanism and policy. Each aspect is broken down into salient dimensions that describe key properties. We break the mechanism into two dimensions, enforcement location and isolation granularity, and break the policy aspect down into three dimensions: policy generation, policy configurability, and policy lifetime. We apply our classification to a set of representative articles that cover a breadth of security isolation techniques and discuss tradeoffs among different design choices and limitations of existing approaches.

bpfbox

“…The process confinement problem dates back half a century [28]. Dozens of tools and frameworks, some more practical than others, have been proposed to limit the impact of untrusted software on the rest of the system [43]. The isolation provided by containers is really a form of operating system virtualization, something that has a long history on Unix, with implementations including the standard chroot(2), BSD jails [25] and Solaris Zones [38].…”

Compiling Sandboxes: Formally Verified Software Fault Isolation

“…Since Wahbe et al [35] proposed their initial technique for SFI, there has been a number of proposals for efficiently confining untrusted software to a memory sandbox (see [23,24,31,32,34,37,39]). One of the most prominent is Google's Native Client (NaCl) [37], which provides an infrastructure for executing untrusted native code in a web browser.…”

A Practical, Lightweight, and Flexible Confinement Framework in eBPF

“…Since the advent of multi-processing and multi-tenant systems in the 1960s and 1970s [36,119,150] with Multics and Unix, security experts have been concerned with designing systems in such a way that two running programs minimally interfere with one another. Since then, an abundance of tools and frameworks, some more practical than others, have been proposed to limit the damage that untrusted software can do to the system as a whole [128]. These are covered in more depth in Chapter 2.…”

“…Mandatory access control solutions based on LSM (Linux Security Modules) hooks can be configured to define and enforce powerful per-application policies, protecting system resources from unwanted access. Unix DAC (Discretionary Access Control) [75,107,119,128] restricts access to system resources according to resource owners, groups, permission bits, and access control lists. When applied to container security, the common problem faced by these security mechanisms is that they are being applied to solve a problem for which they were not originally designed.…”

“…Although discretionary access control provides a convenient and intuitive user-centric model for object ownership and permissions, it makes some dangerous assumptions about security that can totally invalidate the model in practice [128]. In particular, DAC assumes that all processes are benign and contain no exploitable vulnerabilities.…”