Leveraging IPsec for Distributed Authorization Trent Jaeger ∗ David King ∗ Kevin Butler ∗ Jonathan McCune ◦ Ram´ on C´ aceres † Serge Hallyn ‡ Joy Latten ‡ Reiner Sailer † Xiolan Zhang † ∗ Department of Computer Science and Engineering, The Pennsylvania State University, University Park PA 16802 USA ◦ Department of Electrical and Computer Engineering, Carnegie-Mellon University, Pittsburgh PA 15213 USA † IBM T.J.Watson Research Center, Hawthorne NY 10532 USA ‡ IBM Linux Technology Center, Hawthorne NY 10532 USA Abstract Mandatory access control (MAC) enforcement is becoming available for commercial environments. For example, Linux 2.6 includes the Linux Security Modules (LSM) framework that enables the enforcement of MAC policies (e.g., Type Enforcement or Multi-Level Security) for individual systems. While this is a start, we envision that MAC enforcement should span multiple machines. The goal is to be able to control in- teraction between applications on different machines based on MAC policy. In this paper, we describe a recent extension of the LSM framework that enables labeled network communication via IPsec that is now available in mainline Linux as of version 2.6.16. This functionality enables machines to control commu- nication with processes on other machines based on the security label assigned to an IPsec security association. We outline a se- curity architecture based on labeled IPsec to enable distributed MAC authorization. In particular, we examine the construc- tion of a xinetd service that uses labeled IPsec to limit client access on Linux 2.6.16 systems. We also discuss the applica- tion of labeled IPsec to distributed storage and virtual machine access control. 1 Introduction Mandatory access control (MAC) enforcement has ar- rived for commercial operating systems, such as Linux 2.6. With the Linux Security Modules (LSM) frame- work [22], Linux has a comprehensive reference moni- tor implementation, and MAC enforcement systems have been built to leverage this infrastructure. For example, RedHat includes the SELinux [14] LSM enabled in its Fedora Core 5 distribution. However, application of LSM has focused on a sin- gle machine at a time. For example, SELinux MAC pol- icy covers 29 different types of objects, but control of network communication has been primitive to date. The SELinux system controls which ports, IP addresses, and network interfaces a process may use, but such controls are notoriously flawed (e.g., IP spoofing) and coarse- grained. What we want is to be able to control communica- tion, such that we can determine whether two processes on two different machines are permitted to communicate with one another. Two machines X and Y have n and m processes, respectively. A reference monitor (e.g., LSM) on X must be able to determine whether a process X i can communicate each particular process Y j on Y in an inde- pendent manner based on MAC policy. Further, different application paradigms, such as grid computing, client- server computing, and migrating processes, imply dif- ferent types of enforcement requirements. For example, grid computing implies that only processes with com- mon labels can communicate, whereas client-server sys- tems often permit the server be more privileged than the clients and be able to run limited processing on behalf of clients. In order to enable MAC control of network commu- nication, we have implemented a network access control mechanism for LSM [25] based on IPsec [10, 11, 12, 17]. The mechanism’s design is motivated by prior work that restricted socket access to IPsec security associations for the Flask system [21]. In that work, a process’s access to network communication requires two permissions: (1) a process’s permission to use a socket and (2) a socket’s permission to use a security association. We have ap- plied this same approach to the Linux kernel using the Linux implementation of IPsec, called the XFRM subsys- tem (pronounced “transform”). We call the mechanism labeled IPsec, and our implementation has become avail- able in the mainline kernel as of version 2.6.16. This mechanism goes far beyond the original prototype in that: (1) it is a complete implementation, including IPsec policy management and negotiation; (2) we have experi- ence using it on real applications; and (3) it is part of a widely used system. In this paper, we examine the application of Linux la- beled IPsec to build secure systems. Our primary exam- ple the xinetd program, a (more) secure version of the old inetd program that launches server programs upon