Asbestos, a new prototype operating system, provides novel labeling and isolation mechanisms that help contain the effects of exploitable software flaws. Applications can express a wide range of policies with Asbestos’s kernel-enforced label mechanism, including controls on inter-process communication and systemwide information flow. A new event process abstraction provides lightweight, isolated contexts within a single process, allowing the same process to act on behalf of multiple users while preventing it from leaking any single user’s data to any other user. A Web server that uses Asbestos labels to isolate user data requires about 1.5 memory pages per user, demonstrating that additional security can come at an acceptable cost.

The file protection mechanism provided in UNIX is insufficient for current computing environments. While the UNIX file protection system attempts to protect users from attacks by other users, it does not directly address the agents of destruction--- executing processes. As computing environments become more interconnected and interdependent, there is increasing pressure and opportunity for users to acquire and test non--secure, and possibly malicious, software. We introduce TRON, a process--level discretionary access control system for UNIX. TRON allows users to specify capabilities for a process' access to individual files, directories, and directory trees. These capabilities are enforced by system call wrappers compiled into the operating system kernel. No privileged system calls, special files, system administrator intervention, or changes to the file system are required. Existing UNIX programs can be run without recompilation under TRON--enhanced UNIX. Thus, TRON improves UNIX secu...

The advent of Web 2.0 has lead to the proliferation of client-side code that is typically written in JavaScript. This code is often combined or mashed-up with other code and content from disparate, mutually untrusting parties, leading to undesirable security and reliability consequences. This paper proposes GATEKEEPER, a mostly static approach for soundly enforcing security and reliability policies for JavaScript programs. GATEKEEPER is a highly extensible system with a rich, expressive policy language, allowing the hosting site administrator to formulate their policies as succinct Datalog queries. The primary application of GATEKEEPER is in reasoning about JavaScript widgets such as those hosted by widget portals Live.com and Google/IG. Widgets submitted to these sites can be either malicious or just buggy and poorly written, and the hosting site has the authority to reject the submission of widgets that do not meet the site’s security policies. To show the practicality of our approach, we describe nine representative security and reliability policies. Statically checking these policies results in 1,341 verified warnings in 684 widgets, no false negatives, due to the

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. Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures—Domain-specific architectures; D.4.5 [Operating Systems]: Reliability—Fault tolerance;

Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic commerce would be unreachable. Cryptographic protocol design is too hard and expensive, given our unlimited need for new contracts.

Asbestos, a new operating system, provides novel labeling and isolation mechanisms that help contain the effects of exploitable software flaws. Applications can express a wide range of policies with Asbestos’s kernel-enforced labels, including controls on interprocess communication and systemwide information flow. A new event process abstraction defines lightweight, isolated contexts within a single process, allowing one process to act on behalf of multiple users while preventing it from leaking any single user’s data to others. A Web server demonstration application uses these primitives to isolate private user data. Since the untrusted workers that respond to client requests are constrained by labels, exploited workers cannot directly expose user data except as allowed by application policy. The server application requires 1.4 memory pages per user for up to 145,000 users and achieves connection rates similar to Apache, demonstrating that additional security can come at an acceptable cost.

Many types of information available in a pervasive computing environment, such as people location information, should be accessible only by a limited set of people. Some properties of the information raise unique challenges for the design of an access control mechanism: Information can emanate from more than one source, it might change its nature or granularity before reaching its final receiver, and it can flow through nodes administrated by different entities. We propose three design principles for the architecture of an access control mechanism: (1) extract pieces of information in raw data streams early, (2) define policies controlling access at the information level, and (3) exploit information relationships for access control. We describe an example architecture in which we apply these principles. We also report how our earlier work about adding access control to a people location service contributed to the more general access control architecture proposed here.

We address three common misconceptions about capability-based systems: the Equivalence Myth (access control list systems and capability systems are formally equivalent), the Confinement Myth (capability systems cannot enforce confinement), and the Irrevocability Myth (capability-based access cannot be revoked). The Equivalence Myth obscures the benefits of capabilities as compared to access control lists, while the Confinement Myth and the Irrevocability Myth lead people to see problems with capabilities that do not actually exist. The prevalence of these myths is due to differing interpretations of the capability security model. To clear up the confusion, we examine three different models that have been used to describe capabilities, and define a set of seven security properties that capture the distinctions among them. Our analysis in terms of these properties shows that pure capability systems have significant advantages over access control list systems: capabilities provide much better support for least-privilege operation and for avoiding confused deputy problems.

Abstract not found

We identify a class of Web browser implementation vulnerabilities, cross-origin JavaScript capability leaks, which occur when the browser leaks a JavaScript pointer from one security origin to another. We devise an algorithm for detecting these vulnerabilities by monitoring the “points-to ” relation of the JavaScript heap. Our algorithm finds a number of new vulnerabilities in the opensource WebKit browser engine used by Safari. We propose an approach to mitigate this class of vulnerabilities by adding access control checks to browser JavaScript engines. These access control checks are backwardscompatible because they do not alter semantics of the Web platform. Through an application of the inline cache, we implement these checks with an overhead of 1–2 % on industry-standard benchmarks. 1