Beyond Good and Evil: Formalizing the Security Guarantees of Compartmentalizing Compilation

Compartmentalization is good security-engineering practice. By breaking a large software system into mutually distrustful components that run with minimal privileges, restricting their interactions to conform to well-defined interfaces, we can limit the damage caused by low-level attacks such as control-flow hijacking. When used to defend against such attacks, compartmentalization is often implemented cooperatively by a compiler and a low-level compartmentalization mechanism. However, the formal guarantees provided by such compartmentalizing compilation have seen surprisingly little investigation. We propose a new security property, secure compartmentalizing compilation (SCC), that formally characterizes the guarantees provided by compartmentalizing compilation and clarifies its attacker model. We reconstruct our property by starting from the well-established notion of fully abstract compilation, then identifying and lifting three important limitations that make standard full abstraction unsuitable for compartmentalization. The connection to full abstraction allows us to prove SCC by adapting established proof techniques; we illustrate this with a compiler from a simple unsafe imperative language with procedures to a compartmentalized abstract machine.Comment: Nit

Cali: Compiler Assisted Library Isolation

Software libraries can freely access the program's entire address space, and also inherit its system-level privileges. This lack of separation regularly leads to security-critical incidents once libraries contain vulnerabilities or turn rogue. We present Cali, a compiler-assisted library isolation system that fully automatically shields a program from a given library. Cali is fully compatible with mainline Linux and does not require supervisor privileges to execute. We compartmentalize libraries into their own process with well-defined security policies. To preserve the functionality of the interactions between program and library, Cali uses a Program Dependence Graph to track data flow between the program and the library during link time. We evaluate our open-source prototype against three popular libraries: Ghostscript, OpenSSL, and SQLite. Cali successfully reduced the amount of memory that is shared between the program and library to 0.08% (ImageMagick) - 0.4% (Socat), while retaining an acceptable program performance

Balancing Disruption and Deployability in the CHERI Instruction-Set Architecture (ISA)

For over two-and-a-half decades, dating to the first widespread commercial deployment of the Internet, commodity processor architectures have failed to provide robust and secure foundations for communication and commerce. This is in large part due to the omission of architectural features allowing efficient implementation of the Principle of Least Privilege, which dictates that software runs only with the rights it requires to operate [19, 20]. Without this support, the impact of inevitable vulnerabilities is multiplied as successful attackers gain easy access to unnecessary rights – and often, all rights – in software systems

FlexOS: Towards Flexible OS Isolation

At design time, modern operating systems are locked in a specific safety and isolation strategy that mixes one or more hardware/software protection mechanisms (e.g. user/kernel separation); revisiting these choices after deployment requires a major refactoring effort. This rigid approach shows its limits given the wide variety of modern applications' safety/performance requirements, when new hardware isolation mechanisms are rolled out, or when existing ones break. We present FlexOS, a novel OS allowing users to easily specialize the safety and isolation strategy of an OS at compilation/deployment time instead of design time. This modular LibOS is composed of fine-grained components that can be isolated via a range of hardware protection mechanisms with various data sharing strategies and additional software hardening. The OS ships with an exploration technique helping the user navigate the vast safety/performance design space it unlocks. We implement a prototype of the system and demonstrate, for several applications (Redis/Nginx/SQLite), FlexOS' vast configuration space as well as the efficiency of the exploration technique: we evaluate 80 FlexOS configurations for Redis and show how that space can be probabilistically subset to the 5 safest ones under a given performance budget. We also show that, under equivalent configurations, FlexOS performs similarly or better than several baselines/competitors.Comment: Artifact Evaluation Repository: https://github.com/project-flexos/asplos22-a

Preventing Supply Chain Vulnerabilities in Java with a Fine-Grained Permission Manager

Integrating third-party packages accelerates modern software engineering, but introduces the risk of software supply chain vulnerabilities. Vulnerabilities in applications' dependencies are being exploited worldwide. Often, these exploits leverage features that are present in a package, yet unneeded by an application. Unfortunately, the current generation of permission managers, such as SELinux, Docker containers, and the Java Security Manager, are too coarse-grained to usefully support engineers and operators in mitigating these vulnerabilities. Current approaches offer permissions only at the application's granularity, lumping legitimate operations made by safe packages with illegitimate operations made by exploited packages. This strategy does not reflect modern engineering practice. we need a permission manager capable of distinguishing between actions taken by different packages in an application's supply chain. In this paper, we describe Next-JSM, the first fine-grained ("supply chain aware") permission manager for Java applications. Next-JSM supports permission management at package-level granularity. Next-JSM faces three key challenges: operating on existing JVMs and without access to application or package source code, minimizing performance overhead in applications with many packages, and helping operators manage finer-grained permissions. We show that these challenges can be addressed through bytecode rewriting; appropriate data structures and algorithms; and an expressive permission notation plus automated tooling to establish default permission. In our evaluation, we report that Next-JSM mitigates 11 of the 12 package vulnerabilities we evaluated and incurs an average 2.72% overhead on the Dacapobench benchmark. Qualitatively, we argue that Next-JSM addresses the shortcomings of the (recently deprecated) Java Security Manager (JSM).Comment: 15 pages, 5 figures, 5 table

Spons & shields: practical isolation for trusted execution

Trusted execution environments (TEEs) promise a cost-effective, “lift-and-shift” solution for deploying security-sensitive applications in untrusted clouds. For this, they must support rich, multi-component applications, but a large trusted computing base (TCB) inside the TEE risks that attackers can compromise application security. Fine-grained compartmentalisation can increase security through defense-in-depth, but current solutions either run all software components unprotected in the same TEE, lack efficient shared memory support, or isolate application processes using separate TEEs, impacting performance and compatibility. We describe the Spons & Shields framework (SSF) for Intel SGX TEEs, which offers intra-TEE compartmentalisation using two new abstraction, Spons and Shields. Spons and Shields generalise process, library and user/kernel isolation inside the TEE while allowing for efficient memory sharing. When users deploy unmodified multi-component applications in a TEE, SSF dynamically creates Spons (one per POSIX process or library) and Shields (to enforce a given security policy for memory accesses). Applications can be hardened with minor code changes, e.g., by using a separate Shield to isolate an SSL library. SSF uses compiler instrumentation to protect Shield boundaries, exploiting MPX instructions if available. We evaluate SSF using a complex application service (NGINX, PHP interpreter and PostgreSQL) and show that its overhead is comparable to process isolation