Operating systems must be flexible in their support for security policies, providing sufficient mechanisms for supporting the wide variety of real-world security policies. Such flexibility requires controlling the propagation of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted access rights. Previous systems are lacking in at least one of these areas. In this paper we present an operating system security architecture that solves these problems. Control over propagation is provided by ensuring that the security policy is consulted for every security decision. This control is achieved without significant performance degradation through the use of a security decision caching mechanism that ensures a consistent view of policy decisions. Both fine-grained access rights and revocation support are provided by mechanisms that are directly integrated into the service-providing components of the system. The architecture is described through its prototype implementation in the Flask microkernelbased operating system, and the policy flexibility of the prototype is evaluated. We present initial evidence that the architecture’s impact on both performance and code complexity is modest. Moreover, our architecture is applicable to many other types of operating systems and environments. 1

This paper describes a novel approach to providing modular and extensible operating system functionality and encapsulated environments based on a synthesis of microkernel and virtual machine concepts. We have developed a software-based virtualizable architecture called Fluke that allows recursive virtual machines (virtual machines running on other virtual machines) to be implemented efficiently by a microkernel running on generic hardware. A complete virtual machine interface is provided at each level; efficiency derives from needing to implement only new functionality at each level. This infrastructure allows common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to be provided by cleanly modularized, independent, stackable virtual machine monitors, implemented as user processes. It can also provide uncommon or unique OS features, including the above features specialized for particular applications ’ needs, virtual machines transparently distributed cross-node, or security monitors that allow arbitrary untrusted binaries to be executed safely. Our prototype implementation of this model indicates that it is practical to modularize operating systems this way. Some types of virtual machine layers impose almost no overhead at all, while others impose some overhead (typically 0–35%), but only on certain classes of applications.

First-generation µ-kernels have a reputation for being too slow and lacking sufficient flexibility. To determine whether L4, a lean second-generation µ-kernel, has overcome these limitations, we have repeated several earlier experiments and conducted some novel ones. Moreover, we ported the Linux operating system to run on top of the L4 µ-kernel and compared the resulting system with both Linux running native, and MkLinux, a Linux version that executes on top of a firstgeneration Mach-derived µ-kernel. For L 4 Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a userlevel version of MkLinux. These numbers demonstrate both that it is possible to implement a high-performance conventional operating system personality above a µ-kernel, and that the performance of the µ-kernel is crucial to achieve this. Further experiments...

Abstract Single-address-space operating systems (SASOS) are an attractive model for making the best use of the wide address space provided by the latest generations of microprocessors. SASOS remove the address space boundaries which make data sharing between processes difficult and expensive in traditional operating systems. They offer the potential of significant performance advantages for applications where sharing is important, such as object-oriented databases or persistent programming systems. We have built the Mungi system to demonstrate that a SASOS can offer these performance advantages without resorting to special hardware. Mungi is a very "pure " SASOS, featuring an unintrusive protection model based on sparse capabilities, a fast protected procedure call mechanism, and uses shared memory as the exclusive inter-process communication mechanism, as well as for I/O. The simplicity of our model makes it easy to implement it efficiently on conventional architectures.

this paper, we define an access control model with the following properties: (1) system administrators can define system access control requirements on applications and (2) application developers can use the same architecture to enforce application access control requirements without the need for ad hoc security mechanism. This access control model uses features of role-based access control models to enable: (1) specification of a single role that applies to multiple application instances; (2) selection of a content's access rights based on the content's application and role in the application; (3) consistency to be maintained between application state and content access rights; and (4) control of role administration. We then detail a system architecture that uses this access control model to implement secure collaborative applications. Lastly, we describe an implementation of this architecture, called the Lava security architecture.

With the development of new client-server computing models, such as thin clients and network computers, the performance of servers becomes a bottleneck. In these models, servers support a large number of clients. They download significant amounts of data to their clients in the form of graphics, executables (e.g., applets), and video. We present an architecture for building highperformance server systems that can efficiently serve large local clusters of NCs or other clients. The key component in our architecture is a generic cache module that is designed to fully utilize available bus bandwidth. Our experiments show that such a server system can achieve throughput rates of up to 36,000 transactions per second. We detail the design and implementation of the generic cache component, describe its use in the implementation of a sample server system, and show how the architecture can be scaled.

We present a mechanism for inter-process communication (IPC) redirection that enables efficient and flexible access control for micro-kernel systems. In such systems, services are implemented at user-level, so IPC is the only means of communication between them. Thus, the system must be able to mediate IPCs to enforce its access control policy. Such mediation must enable enforcement of security policy with as little performance overhead as possible, but current mechanisms either: (1) place significant access control functionality in the kernel which increases IPC cost or (2) are static and require more IPCs than necessary to enforce access control. We define an IPC redirection mechanism that makes two improvements: (1) it removes the management of redirection policy from the kernel, so access control enforcement can be implemented outside the kernel and (2) it separates the notion of who controls the redirection policy from the redirections themselves, so redirections can be configured arbitrarily and dynamically. In this paper, we define our redirection mechanism, demonstrate its use, and examine possible, efficient implementations. 1.

A goal of World-wide Web operating systems (WebOSes) is to enable clients to download executable content from servers connected to the World-wide Web (WWW). This will make applications more easily available to clients, but some of these applications may be malicious. Thus, a WebOS must be able to control the downloaded content's behavior. In this paper, we examine a specific type of malicious activity: denial-of-service attacks using legal system operations. A denial-of-service attack occurs when an attacker prevents other users from performing their authorized operations even when the attacker may not be able to perform such operations. Current systems either do little to prevent denial-of-service attacks or have a limited scope of prevention of such attacks. For a WebOS, however, the ability to prevent denial-of-service should be an integral part of the system. We are developing a WebOS using the L4 μ-kernel as its substrate. In this paper, we evaluate L4 as a basis of a system that can prevent...

From a software-technology point of view, the-kernel concept is superior to large integrated kernels. On the other hand, it is widely believed that (a)-kernel based systems are inherently ine cient and (b) they are not su ciently exible. Contradictory to this belief, we show and support by documentary evidence that ine ciency and in exibility ofcurrent-kernels is not inherited from the basic idea but mostly from overloading the kernel and/or from improper implementation. Based on functional reasons, we describe some concepts which must be implemented by a-kernel and illustrate their exibility. Then, we analyze the performance critical points. We showwhat performance is achievable, that the e ciency is su cient withrespect to macro-kernels and why some published contradictory measurements are not evident. Furthermore, we describe some implementation techniques and illustrate why-kernels are inherently not portable, although they improve portability of the whole system. 1

Model of Address Spaces We describe address spaces as mappings. # # # # # ##### is the initial address space, where # is the set of virtual pages, # the set of available physical (real) pages and # the nilpage which cannot be accessed. Further address spaces are defined recursively as mappings # # # # ## # # # ####, where # is the set of address spaces. It is convenient to regard each mapping as a one column table which contains #### for all ### and can be indexed by #. We denote the elements of this table by # # . All modifications of address spaces are based on the replacement operation: we write # # # # to describe a change of # at #, precisely: flush #### # # # # ## # # A page potentially mapped at # in # is flushed, and the new value # is copied into # # . This operation is internal to the #-kernel. We use it only for describing the three exported operations. A subsystem # with address space # can grant any of its pages # to a subsystem # # # # Note that # determines which of its pages should be granted, whereas # determines at which virtual address the granted page should be mapped in # . The granted page is transferred to # and removed from #.