Security in Plan 9

The security architecture of the Plan 9″ operating system has
recently been redesigned to address some technical shortcomings. This
redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually
seen together: it has become more secure and easier to use.
The central component of the new architecture is a per-user selfcontained agent called factotum. Factotum securely holds a copy of
the users keys and negotiates authentication protocols, on behalf of the
user, with secure services around the network. Concentrating security
code in a single program offers several advantages including: ease of
update or repair to broken security software and protocols; the ability to
run secure services at a lower privilege level; uniform management of
keys for all services; and an opportunity to provide single sign on, even
to unchanged legacy applications. Factotum has an unusual architecture: it is implemented as a Plan 9 file server.

Source: https://plan9.io/sys/doc/auth.pdf

Advertisements

The Use of Name Spaces in Plan 9

Plan 9 is a distributed system built at the Computing Sciences
Research Center of AT&T Bell Laboratories (now Lucent Technologies, Bell
Labs) over the last few years. Its goal is to provide a production-quality
system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU
and file servers in a central location connected together by fast networks.
Slower networks fan out to workstation-class machines that serve as user
terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides
support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a perprocess name space and a simple message-oriented file system protocol.

Source: https://plan9.io/sys/doc/names.pdf

Open-sourcing gVisor, a sandboxed container runtime | Google Cloud Blog

Containers have revolutionized how we develop, package, and deploy applications. However, the system surface exposed to containers is broad enough that many security experts don’t recommend them for running untrusted or potentially malicious applications.

A growing desire to run more heterogenous and less trusted workloads has created a new interest in sandboxed containers—containers that help provide a secure isolation boundary between the host OS and the application running inside the container.

To that end, we’d like to introduce gVisor, a new kind of sandbox that helps provide secure isolation for containers, while being more lightweight than a virtual machine (VM). gVisor integrates with Docker and Kubernetes, making it simple and easy to run sandboxed containers in production environments.

Source: https://cloud.google.com/blog/products/gcp/open-sourcing-gvisor-a-sandboxed-container-runtime

The Security Architecture of the Chromium Browser

Most current web browsers employ a monolithic architecture
that combines “the user” and “the web” into a single
protection domain. An attacker who exploits an arbitrary
code execution vulnerability in such a browser can steal sensitive
files or install malware. In this paper, we present the
security architecture of Chromium, the open-source browser
upon which Google Chrome is built. Chromium has two
modules in separate protection domains: a browser kernel,
which interacts with the operating system, and a rendering
engine, which runs with restricted privileges in a sandbox.
This architecture helps mitigate high-severity attacks without
sacrificing compatibility with existing web sites. We
define a threat model for browser exploits and evaluate how
the architecture would have mitigated past vulnerabilities.

Source: http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf

Lockdown: Towards a Safe and Practical Architecture for Security Applications on Commodity Platforms

We investigate a new point in the design space of red/green systems [19,
30], which provide the user with a highly-protected, yet also highly-constrained trusted (“green”) environment for performing security-sensitive transactions, as well as a high-performance, general-purpose environment for all other (non-security-sensitive or “red”) applications. Through the design and implementation of the Lockdown architecture, we evaluate whether partitioning, rather than virtualizing, resources and devices can lead to better security or performance for red/-green systems. We also design a simple external interface to allow the user to securely learn which environment is active and easily switch between them. We find that partitioning offers a new tradeoff between security, performance, and usability. On the one hand, partitioning can improve the security of the “green” environment and the performance of the “red” environment (as compared with a virtualized solution). On the other hand, with current systems, partitioning makes switching between environments quite slow (13-31 seconds), which may prove intolerable to users.

Source: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/39968.pdf

Isolating Web Programs in Modern Browser Architectures

Many of today’s web sites contain substantial amounts of
client-side code, and consequently, they act more like programs
than simple documents. This creates robustness and
performance challenges for web browsers. To give users a
robust and responsive platform, the browser must identify
program boundaries and provide isolation between them.
We provide three contributions in this paper. First, we
present abstractions of web programs and program instances,
and we show that these abstractions clarify how
browser components interact and how appropriate program
boundaries can be identified. Second, we identify backwards
compatibility tradeoffs that constrain how web content can
be divided into programs without disrupting existing web
sites. Third, we present a multi-process browser architecture
that isolates these web program instances from each other,
improving fault tolerance, resource management, and performance.
We discuss how this architecture is implemented in
Google Chrome, and we provide a quantitative performance
evaluation examining its benefits and costs.

Source: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34924.pdf