1 / 21

Distributed Security Model for Linux Clusters

Distributed Security Model for Linux Clusters. Brian Schoudel I2CS. 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. Agenda.

edric
Download Presentation

Distributed Security Model for Linux Clusters

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related