figure 7. components of the histar Web server, their complexity measured in lines of c code (not including libraries such as libc), their label and ownership, and the worst-case results of the component being compromised. the netd tcP/iP stack is a modified Linux kernel; histar also supports the lwiP tcP/iP stack, consisting of 35,000 lines of code, which has lower performance.

Component Lines of Code Label Ownership Effects of Compromise
netd 350,000 ∅
∅
∅
∅

Equivalent to an active network attacker; subject to same kernel label checks as any other process
launcher 310 ∅ Obtain plaintext requests, including passwords, and subsequently corrupt user data
SSLd 340,000 Corrupt request or response, or send unencrypted data to same user’s browser
RSAd 4,600 Disclose the server’s SSL certificate private key
httpd 300 Full access to data in attacker’s account, but not to other users’ data
authentication 320 Full access to data of the user whose agent is compromised, but no password disclosure
application 680,000+ Send garbage (only to the same user’s browser), corrupt user data (for write requests)

{sslr}

{rsar}
{sslr}
{sslr}
{ur} {uw}
{nr, nw}
{ur, uw, sslr}
{ur, uw}

they are malicious. The application code is confined by the user’s secrecy category, ur, and it is httpd’s job to ensure that the application code is labeled with ur when httpd runs it. Although the application code owns the user’s integrity category, uw, this gives it the privilege to write only that one user’s files, and not to export them. Ownership of uw is necessary to allow the application code to read data not labeled with uw. If the application code were to be labeled with uw, it would be restricted to reading only data labeled uw, which would exclude executables, shared libraries, and configuration files.

SSLd is confined by sslr, a fresh secrecy category allocated by the launcher for each new connection. Both the launcher and httpd own sslr, allowing them to freely handle encrypted and decrypted SSl data, respectively. However, SSLd can communicate only with httpd and, via the launcher, with the user’s Web browser.

SSLd is not trusted to handle the SSL certificate private key. Instead, a separate and much smaller daemon, RSAd, has access to the private key and provides an interface to generate RSA signatures for SSL session key establishment. Not shown in Figure 7 is a category owned by SSLd that ensures no other process can invoke RSAd. Since SSLd is confined by sslr, the kernel ensures that SSLd cannot indirectly divulge any data to another process via its calls to RSAd, much as described in Section 3. 5.

The HiStar authentication service used by httpd to authenticate users is described in detail in Zeldovich et al., 18 but briefly, no code executes with all users’ privileges, and the supplied password cannot be leaked even if the password checker is malicious. Our Web server does not use SSL client certificates for authentication. Doing so would require either trusting all of SSLd to authenticate users, or moving the client certificate code into the authentication agent. In comparison, the password checking agent is 320 lines of code.

One caveat of our prototype is its lack of SSL session caching. Because a separate instance of SSLd is used for each client request, clients cannot reuse existing session keys when connecting multiple times, requiring public key cryptography to establish a new session key. This limitation can be addressed by adding an SSL session cache that runs in a separate persistent process and owns all sslr categories, at the cost of increasing the amount of trusted code.

5. ReLateD WoRk

providing systemwide persistence and a lower-level kernel interface that closes known covert storage channels. While Asbestos is a message-passing system, HiStar relies heavily on shared memory. The HiStar kernel provides gates, not IPC, with the important distinction that upon crossing a gate, a thread’s resources initially come from its previous domain. By contrast, Asbestos changes a process’s label to track information flow when it receives IPCs, which is detectable by third parties and can leak information. Asbestos optimizes comparisons between enormous labels, which so far we have not done in HiStar.

Flume8 showed how to provide information flow control on top of the Linux kernel, and introduced a cleaner label system (which HiStar and this paper have adopted). Flume also proposed endpoints to help programmers reason about labels on standard Unix abstractions; adopting endpoints in HiStar’s Unix library would similarly help HiStar programmers. DStar19 extended information flow control to decentralized systems and developed the HiStar Web server. Loki20 showed how hardware can partially enforce HiStar’s labels, to reduce the amount of fully trusted kernel code.

HiStar controls information flow with mandatory access control (MAC), a well-studied technique dating back decades. 1 The ADEPT- 50 dynamically adjusted labels (essentially taint tracking) using the High-Water-Mark security model back in the late 1960s9; the idea has often resurfaced, for instance in IX12 and LOMAC. 5 HiStar and its predecessor Asbestos are novel in that they make operations such as category allocation and untainting available to application programmers, where previous OSes reserved this functionality for security administrators. Decentralized untainting allows novel uses of categories that we believe promote better application structure and support applications such as Web services, which were not targeted by previous MAC systems.

Like HiStar, capability-based KeyKOS3 and EROS17 use a small number of kernel object types and a single-level store. HiStar’s containers are reminiscent of hierarchical space banks in KeyKOS. However, while KeyKOS uses kernel-level capabilities to enforce labels at user level, HiStar bases all protection on kernel-level labels. The difference is significant because labels specify security properties while imposing less structure on applications; for example, an untrusted thread can dynamically alter its label to observe secret data, which has no analogue in a capability system.