This is an open forum for discussion of papers
presented at OSDI 2006. Please add your comments
to these postings. We invite comments from anyone
who has read the paper or heard the presentation;
please note that the papers themselves are not available for free online access until 2007.

Tuesday, October 31, 2006

Paper: "Making Information Flow Explicit in HiStar"

Making Information Flow Explicit in HiStarNickolai Zeldovich and Silas Boyd-Wickizer, Stanford University; Eddie Kohler, University of California, Los Angeles; David Mazières, Stanford University

Abstract

HiStar is a new operating system designed to minimize the amount of code that must be trusted. HiStar provides strict information flow control, which allows users to specify precise data security policies without unduly limiting the structure of applications. HiStar's security features make it possible to implement a Unix-like environment with acceptable performance almost entirely in an untrusted user-level library. The system has no notion of superuser and no fully trusted code other than the kernel. HiStar's features permit several novel applications, including an entirely untrusted login process, separation of data between virtual private networks, and privacypreserving, untrusted virus scanners.

2 Comments:

The HiStar operating system aims to prevent malicious and buggy software from leaking sensitive user data by making all information flow within the system explicit. The HiStar kernel implements six types of objects used as building blocks for user-level software: containers, segments, address spaces, threads, gates, and devices. Each object is assigned a security label that acts as a taint. Data in a tainted object can only be accessed by other tainted objects. Any data that flows outside the system has to be untainted first. Untainting can only be performed by a thread that has an untaint label.

Taints allow avoiding certain types of covert channels. For example, in most conventional systems a malicious application can infer some information from the fact of being forbidden to perform an IPC call. In contrast, the HiStar approach is to allow IPC but taint the caller with the callee's label.

Flexibility is achieved by introducing multiple categories of taint. For example, UNIX users can be emulated by assigning a taint category to each user. A superuser can then be implemented as a thread holding untaint privilege for all user categories.

Nickolai illustrated the HiStar architecture using two case studies. First, a running example of a virus scanner was used to introduce the taint-based access control model and demonstrate how HiStar allowed encapsulating application-specific security policies in a separate component. Second, an implementation of the UNIX authentication process based on an untrusted authentication service was described.

Q&A===

Two main groups of questions were about the HiStar resource management policy and dealing with different types of covert channels. Nickolai explained that while HiStar supported dynamic resource allocation, the preferred method was static preallocation of most required resources for a task. For IPC, initial resources, including stack, are provided by the calling thread.

With regards to covert channels, someone asked how HiStar dealt with latency-based covert channels. Nickolai replied that, while they were working on some ideas, the current implementation did not do anything to prevent such channels. Another question was whether the authentication service could leak the password by denying and allowing login requests. The answer was that this could not happen, since every request is essentially handled by a newly forked instance of the authentication service, which is not allowed to communicate any data back to the original instance of the service.

Another interesting question was whether HiStar could accommodate legacy applications requiring communication with the outside world. Nickolai said that, while this could be achieved by giving the application untaint capability, this would violate the HiStar philosophy and should be avoided.

The HiStar operating system aims to prevent malicious and buggy software from leaking sensitive user data by making all information flow within the system explicit. The HiStar kernel implements six types of objects used as building blocks for user-level software: containers, segments, address spaces, threads, gates, and devices. Each object is assigned a security label that controls how the object can be modified or observed, and can be thought of as a taint. Data in a tainted object can only be accessed by other tainted objects. Any data that flows outside the system has to be untainted first. Untainting can only be performed by a thread that has an untaint label.

Coming up with the right design of taint tracking can be difficult, if one wants to avoid covert channels. In a naive design, malicious applications could communicate by modifying and observing taint levelsof different objects. HiStar closes this covert channel by making all non-thread object labels immutable. To avoid covert channels arising from resource allocation, HiStar provides a specialized IPC abstraction where the client donates initial resources to the server.

Flexibility is achieved by introducing multiple categories of taint. For example, UNIX users can be emulated by assigning a taint category to each user. A superuser can then be implemented as a thread holding untaint privilege for all user categories. As a result, root has no special privileges in the system, and is not fundamentally trusted by the kernel.

Nickolai illustrated the HiStar architecture using two case studies. First, a running example of a virus scanner was used to introduce the taint-based access control model and demonstrate how HiStar allowed encapsulating application-specific security policies in a separate component. Second, an implementation of the UNIX authentication process based on an untrusted authentication service was described.

Q&A===

Two main groups of questions were about the HiStar resource management policy and dealing with different types of covert channels. Nickolai explained that static preallocation of resources is preferred in cases where you really want tight control over information flow, but in less-sensitive applications that is likely to be too restrictive.

With regards to covert channels, someone asked how HiStar dealt with latency-based covert channels. Nickolai replied that, while they were working on some ideas, the current implementation did not do anything to prevent such channels. Another question was whether the authentication service could leak the password bydenying and allowing login requests. The answer was that this could not happen, since every request is essentially handled by a newly forked instance of the authentication service, which is not allowed to communicate any data back to the original instance of the service.

Another interesting question was whether HiStar could accommodate legacy applications requiring communication with the outside world. Nickolai said that HiStar could accommodate most legacy applications, but it may not be able to provide any added security if the application is monolithic and requires frequent network interaction.