With the inclusion of the Linux Security Modules (LSM) framework in Linux 2.6, comprehensive mandatory access control (MAC) enforcement is available in the Linux kernel. MAC enables system-level control of access to resources which prevents a compromised process from allocating its access rights to unauthorized users and enables finer-grained control of the rights available to root processes. Also, the LSM is comprehensive in that it aims to control access to all security-sensitive operations to all kernel objects, including files, sockets, superblocks, IPC, shared memory, etc.
However, network control in the initial version of the LSM was primitive initially. Access to packet delivery/reciept was based on IP address, port, and network interface. This was rather coarse-grained, and, in the case of IP address, could be spoofed by malicious sources. The initial proposal for packet-level access control was based on the IP Security Options protocol, where packet labels are included in a special options IP header. Because this approach required a significant number of hooks for parsing IP headers and maintaining labels across fragmentation/defragmentation, it was rejected from inclusion in the original LSM.
We implement an alternative approach to network control for the LSM that leverages IPsec to control access to network communications. This work is based on the prototype IPsec controls introduced into the Flask system by Chitturi (a Masters' thesis supported by the Flask team which included the SELinux development team). Here, labels are attached to IPsec objects such that network communications associate packets with the labels of the security association upon which they were sent. Because access to particular IPsec security associations can be limited at the application level, application-to-application access control can be enforced across systems (assuming trust in the underlying OSes on both machines).
The initial aim for the IPsec network control is for multi-level security (MLS) enforcement for the Linux Labeled Security Protection Profile (LSPP) version, but the IPsec network hooks can enforce any application-to-application level MAC policy. We envision use in: (1) setting up isolated application components on different machines to communicate in a protected way (non-interference); (2) MLS enforcement of inter-application communication; (3) the creation of servers that can create label-specific worker threads to enforce access control; and (4) location-independence between the application components and the machines that they run upon. We are applying IPsec network controls to MAC control of distributed storage. Also, the IPsec network controls are part of the Xen-based distributed reference monitor prototype described here.
Extracting the label of peer of a socket communication (TCP or UDP) will be available in 2.6.18.
Venkat Yekkirala of TCS has extended the original work on Labeled IPsec to enable full SELinux MLS enforcement to be available in 2.6.19.
Trent Jaeger, Kevin Butler, David H. King, Serge Hallyn, Joy Latten, and Xiaolan Zhang. Leveraging IPsec for Mandatory Access Control of Across Systems.. In Proceedings of the Second International Conference on Security and Privacy in Communication Networks. August, 2006.
Leveraging IPsec for Mandatory Access Control of Linux Network Commmunications. 2005. Research Report, RC23642, IBM T.J. Watson Research Center. (Presented at 21st Annual Computer Security Applications Conference; Tucson, Arizona; December 2005)The LSM-IPsec integration is joint work with Serge Hallyn and Joy Latten of the IBM Linux Technology Center. Catherine Zhang of IBM Watson has joined the work (e.g., peer label extraction).
We thank Stephen Smalley, James Morris, and Herbert Xu for their comments throughout the development process.
Back to Trent Jaeger's Home Page CSE Department Pennsylvania State University