Distributed Security Model for Linux Clusters

1. Distributed Security Model for Linux Clusters Brian Schoudel I2CS

2. Research Basis • Based on paper: A new Distributed Security Model for Linux Clusters Makan Pourzandi, Open Systems Lab, Ericcson Research, Town of Mount-Royal (QC) Canada • 2004 USENIX Annual Technical Conference

3. Agenda • Current Problem set • Proposed Solution • Implementation • Test Results • Future Work

4. Current Problem • Greater use of clustering – Demands more efficient, flexible, and distributed security model • Current solutions based on user permissions that work well on small scale – not flexible enough for large distributed applications • User based security doesn’t provide authentication and authorization checks for interactions between two processes of the same user

5. Current Problem cont.. • All or nothing – users in a group or all processes of the same user have same rights • Lack of compartmentalization – small component may compromise the system • Assemblage of hetergeneous security solutions for different nodes – security management nightmare

6. Proposed Cluster Wide Security Space Solution • Process level granularity (currently set at user level) • Mandatory Access Control (MAC) at cluster level • Security zones inside cluster

7. Process Level Granularity • Security Node Identifier (SnID) – assigned to each node in cluster • Security Context Identifier (ScID) – defined for processes, binary files, and resources on cluster • Persistent (don’t change after reboot) • More like group IDs (GIDs) than process IDs (PIDs) • Groups together processes and resources falling under same security context

8. Process Level Granularity cont.. • A new process is assigned a ScID based on ScID of parent process, ScID stored in loaded binary, and general security context of system • Security Mechanisms (access control, authentication, confidentiality, integrity, and logging) based on pair (ScID, SnID)

9. Mandatory Access Control vs Discretionary Access Control • Discretionary Access Control (DAC) • Object’s permissions set by owners • Buggy process allows access to all resources available to owner • Used in Buffer Overflow Exploits to allow attacker to gain root privilege to system • Mandatory Access Control (MAC) • Remedies this problem in Linux

10. Mandatory Access Control cont.. • Access control based on user’s decision as well as security relevant information • Broken into two types of programs – “secure” and “handle with care”. • “Secure” able to spawn new processes • “Handle with care” unable to spawn new processes • No standard way yet of implementing MAC • SE Linux project http://www.nsa.gov/selinux/ is the best example of this

11. MAC at the cluster level • Extend access control checks at kernel level of each node to entire cluster • Kernel level access control check based on ScID and SnID and independent of location of process  effective cluster wide verification • Independent of security implemented at application level (important for untrusted code running)

12. Security Zones • Created by defining security rules for interactions between different processes and resources through the cluster • Example rule: processes on node 1 with ScID=2 may create sockets and connect to processes on node 2 with ScID=2. • Administrator creates a security zone to access all zones

13. Security Zones cont… • Distributed Security Policy (DSP) stores all the security rules • Security rules applied to pairs of (SnID, ScID) • DSP pushed out to all cluster nodes at system initialization and after modifications • Rules cached in kernel memory for fast access

14. Distributed Security Policy (DSP) • DSP example for socket: • Current support mainly focused on network communication and process creation

15. DSP cont.. • Current supported DSP permissions: • Allow or deny process creation • Sockets using TCP and UDP (create, bind) • Networking – allowing or denying access to send or receive network information • Transition class defines how ScIDs are assigned to processes according to the ScID stored in their binary file and their parent process

16. Security Zone Diagram

17. Implementation - DSI • Distributed Security Infrastructure (DSI) • Composed of: • one security server (SS) – central point of management • multiple security managers (SM) – one per node • distributed security module (DSM) – one per node inside the kernel • Administrative messages between SMs and SS sent along encrypted and authenticated channels

18. DSI Diagram

19. DSI Benchmark results • Tests using LMBench 3.0 • Linux 2.4.17 kernel w/ and w/out DSI.

20. Future Work • Having right DSP was a challenging and a daunting task to define all the rules explicitly • Future plan to simplify DSP rule creation for interactions of all processes and resources of same security zone

21. References • M. Pouzandi, A new Distributed Security Model for Linux Clusters, in the proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference. Boston, July 2004. • P. Virijevich, Securing Linux with Mandatory Access Controls, Feb 2005.