2010


   Flask: Flux Advanced
   Security Kernel
   A Project Report for ECE 579S – Computer
   and Network Security (Dr....
ECE 579S - September 2010


Table of Contents
1      The Evolution of the Distributed Operating System ......................
ECE 579S - September 2010

Figure 7 - Security Context usage in SELinux. ....................................................
ECE 579S - September 2010


    1 The Evolution of the Distributed Operating
      System
It is impossible to separate the...
ECE 579S - September 2010




                     Figure 1 - The Multics Multi-User Architecture

1965 The first wide are...
ECE 579S - September 2010




                                   Figure 2 - ARPANET in 1970

1970 The first version of UNI...
ECE 579S - September 2010




                   Figure 3 - The Distributed Operating System, Mach

1987 The first T1 back...
ECE 579S - September 2010


2       Historical Significance
In the early days of computer research and development, the ma...
ECE 579S - September 2010

A 1989 analysis of the two most popular secure distributed systems, SDOS and TMach (Trusted Mac...
ECE 579S - September 2010

invulnerable and the systems themselves are at risk to the weaknesses of the protocols they use...
ECE 579S - September 2010

client makes a request to access an object. The request is handled by object manager. It sends ...
ECE 579S - September 2010




                     Figure 5 - Labeling Operation by Object Manager

Polyinstantiation supp...
ECE 579S - September 2010




       Client (SID –C)



                        Creates Client Object

                   ...
ECE 579S - September 2010

and unload policies. The security server plays a central role in revocation of polices for a pr...
ECE 579S - September 2010




                     Figure 7 - Security Context usage in SELinux.

In Figure 7, subjects re...
ECE 579S - September 2010




                     Figure 8 - LSM Architecture (High Level View)


5.1.2 Kernel and User S...
ECE 579S - September 2010




                   Figure 9 - Kernel view of a SELinux LSM Module

Other object managers tha...
ECE 579S - September 2010

extended attributes so that they represent security contexts as security labels. These labels, ...
ECE 579S - September 2010

In typical UNIX systems, this is implemented by setting a sticky bit on the program performing ...
ECE 579S - September 2010




    Figure 11 - Elevation of access rights (limited to least privilege) via
                ...
ECE 579S - September 2010

(available by default in Ubuntu distributions.) The main differences between these three additi...
ECE 579S - September 2010



    References
[1] http://www.multicians.org/
[2] http://www.computerhistory.org/timeline/
[3...
ECE 579S - September 2010

[Shabial2010] Securing Android-Powered Mobile Devices Using SELinux. Asaf Shabial, Yuval Fledel...
Upcoming SlideShare
Loading in...5
×

Flask: Flux Advanced Security Kernel. A Project Report

872

Published on

This report documents our research and findings on the subject of trusted and secure operating systems. In particular, we focus on the Flask operating system security architecture. Concrete implementations are studied with coverage of their implementation of trusted operating systems computing.

Authored by Samantha Rassner, Sanjay Kumar and Luis Espinal

Published in: Technology
2 Comments
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
872
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
38
Comments
2
Likes
2
Embeds 0
No embeds

No notes for slide

Flask: Flux Advanced Security Kernel. A Project Report

  1. 1. 2010 Flask: Flux Advanced Security Kernel A Project Report for ECE 579S – Computer and Network Security (Dr. Richard Stanley) This report documents our research and findings on the subject of trusted and secure operating systems. In particular, we focus on the Flask operating system security architecture. Concrete implementations are studied with coverage of their implementation of trusted operating systems computing. Samantha Rassner, Sanjay Kumar, Luis Espinal ECE 579S - Worcester Polytechnic Institute 9/21/2010
  2. 2. ECE 579S - September 2010 Table of Contents 1 The Evolution of the Distributed Operating System ............................................................................. 4 1.1 Timeline......................................................................................................................................... 4 2 Historical Significance ........................................................................................................................... 8 3 Modern Computing Environments ....................................................................................................... 9 4 Introducing Flask ................................................................................................................................. 10 4.1 Architecture of Flask ................................................................................................................... 10 4.1.1 Object Manager .................................................................................................................. 11 4.1.2 Access Vector Cache ........................................................................................................... 13 4.1.3 Security Server .................................................................................................................... 13 5 SELinux ................................................................................................................................................ 14 5.1 Architecture ................................................................................................................................ 14 5.1.1 LSM Architecture................................................................................................................. 15 5.1.2 Kernel and User Space ........................................................................................................ 16 5.2 Capabilities .................................................................................................................................. 17 5.2.1 Policy Flexibility ................................................................................................................... 17 5.2.2 Trusted MAC/MLS ............................................................................................................... 18 5.3 Domain Transition....................................................................................................................... 18 5.4 Additional Notes ......................................................................................................................... 20 References .................................................................................................................................................. 22 Figures Figure 1 - The Multics Multi-User Architecture ............................................................................................ 5 Figure 2 - ARPANET in 1970 .......................................................................................................................... 6 Figure 3 - The Distributed Operating System, Mach..................................................................................... 7 Figure 4 - The Flask Architecture ................................................................................................................ 11 Figure 5 - Labeling Operation by Object Manager ...................................................................................... 12 Figure 6 - Polyinstantiation in Flask ............................................................................................................ 13 Rassner, Kumar, Espinal Page 2
  3. 3. ECE 579S - September 2010 Figure 7 - Security Context usage in SELinux. ............................................................................................. 15 Figure 8 - LSM Architecture (High Level View)............................................................................................ 16 Figure 9 - Kernel view of a SELinux LSM Module ........................................................................................ 17 Figure 10 - Elevation of access rights for changing an entry in /etc/shadow ............................................. 19 Figure 11 - Elevation of access rights (limited to least privilege) via domain transitions........................... 20 Examples Example 1 - Security context format as encoded in extended attributes .................................................. 18 Example 2 - Associating a domain (user_t) to a type (bin_t) of file resources for read, execute and view of attributes. ............................................................................................................................................... 18 Rassner, Kumar, Espinal Page 3
  4. 4. ECE 579S - September 2010 1 The Evolution of the Distributed Operating System It is impossible to separate the development of the distributed operating system with the development and evolution of the computer itself. From the beginning, the value of computing machines is based on their capacity to process, and ultimately share, data. At a cost of approx $500,000 in 1946 dollars (approximately $5.6 million in 2010 dollars), the first general purpose computer, ENIAC in 1946, was cost prohibitive to anyone except a few research universities, like MIT, and government institutions like NASA and the Department of Defense. By the 1963, the innovation of components and general cost of computers came down enough so that the field of computer science was an active area of research and development. Progress was spurned forward with the joint proposal for ARPANET in 1967 to develop the first packet switching network – the birth of the Internet. The milestones of the evolution of computers and networking form the background of our discussion of modern secure distributed operating systems. We will take a look at the timeline and pertinent events that influence the direction of FLASK (Flux Advanced Security Kernel) architecture - you have to know your history to understand your future. 1.1 Timeline 1946 ENIAC, the first digital general purpose computer, is completed. ENIAC is transferred to Aberdeen Proving Ground in Aberdeen, Maryland, to perform ballistics analysis, atomic-energy calculations, and meteorological studies among many other scientific projects. 1961 CTSS (Compatible Time Sharing System) was developed. CTSS is the first multi-user operating system, demonstrating in 1961 four users logged in simultaneously through terminals directly connected to the mainframe. CTSS lays the groundwork for Multics, with many of the scientists and engineers working on both projects. 1962 J. C. R. Licklider of MIT begins discussions of networking with DARPA colleagues. 1963 CTSS is capable of connecting remote users to the mainframe via dial-up modems. 1964 Multics development begins. The foundation for UNIX architectures, Multics implements the first operating system access control with the read-write-execute still in use today. Rassner, Kumar, Espinal Page 4
  5. 5. ECE 579S - September 2010 Figure 1 - The Multics Multi-User Architecture 1965 The first wide area network is created between MIT and SDC (System Development Corporation) in Santa Monica is created using dedicated telephone lines and acoustic couplers. From this point on, the computer network of ARPANET continues to expand. Common use of computers in Institutions is to have local networks with multiple terminals, after the first WAN is demonstrated, it is not long before additional locations are added to ARPANET. Rassner, Kumar, Espinal Page 5
  6. 6. ECE 579S - September 2010 Figure 2 - ARPANET in 1970 1970 The first version of UNIX, a scaled down and more efficient version of Multics, is released. 1972-1976 UNIX is released in C, making it usable across many different hardware platforms, and adopted by many universities and research institutions. The built in remote user support directly contributes to advancements in networking development. The Ethernet and TCP/IP protocols are accepted and incorporated into UNIX. 1981 IBM launches the PC, with the MS DOS operating system, making low cost computers available to the general public. 1986 The UNIX based Mach kernel is released. Mach consolidates the varied extensions of UNIX into an architecture specifically designed to be a distributed operating environment. The Mach kernel is still used today in Apple products. Rassner, Kumar, Espinal Page 6
  7. 7. ECE 579S - September 2010 Figure 3 - The Distributed Operating System, Mach 1987 The first T1 backbone installations begin. Implementing DoD security into operating systems becomes a serious topic of discussion and development. 1988 The first commercial traffic is passed on the Internet. SDOS (Secure Distributed Operating System) is proposed as a solution to implement DoD security across an open, unsecured network. 1989 Http is invented in Switzerland, creating a method to distribute information across the network that is machine independent. 1992 Mosaic, the first web browser and precursor to Netscape, is released and the WWW explosion begins. 1998 NSA recognizes shortcomings in available secure operating systems and sponsors a project with the University of Utah to develop a modern and flexible distributed system architecture that could support the stringent information security requirements of the Department of Defense. 1999 NSA introduces the Flask (Flux Advanced Security Kernel) architecture, which becomes the foundation of security in Linux and accepted as the industry standard for security. Rassner, Kumar, Espinal Page 7
  8. 8. ECE 579S - September 2010 2 Historical Significance In the early days of computer research and development, the machines were so size and cost prohibitive that the physical location of the machines that were available at universities and research institutions were well protected and extremely secured. There was no access control implemented in the early operating systems because the only access control needed was access to the actual room where the computers were located. As advancements in computer hardware and software made the machines more accessible, access control in the operating system became a necessity. It was not uncommon to have terminals remote from the mainframes; the first security concern became user identification and authentication. Multics integrates support for user login and access control on each file in the system. UNIX inherits the read- write-execute access control design. Even though there were login capabilities, in the period of 1970s – 1980s, where the people using the computers were the ones doing the development and research, security was not a concern and often password (including the password for root) were not used. The authentication was mostly used for process ownership rather than verifying a user’s credentials. At this time, the development and research was being performed in many universities across the nation, with each of the teams making their own modifications to the UNIX kernel, extending the functionality for their own purposed. The most notable university version of UNIX (and still in use) is that produced by the University of California at Berkley, called BSD (Berkley Software Distribution). The Mach (circa 1986) distributed system architecture is based on the 4.3BSD kernel. While lots of thought and design were put into the client-server architecture to isolate the kernel from the implementation of the applications accessing remote servers, so that the Mach machines operate seamlessly across a network, there was no design for security. The mention of security in the Mach whitepaper briefly mentions maintaining access control permissions across the network nodes and ensuring the port to port connection between the processes on the host and server. While the Mach kernel provided a foundation for distributed system design, it was SDOS, based on the CRONUS military distributed operating system, that was one of the first operating systems to implement the DoD security policies based on the Bell-LaPadula and Biba models. It is SDOS, introduced in 1988, which begins to address the impact of the Internet on the security of a system and the difficulty the security models introduce into the design. The difficulties begin with the designing and implementing a trusted computing base (TCB), a secure kernel and small subset of trusted managers, on a single host – such as not violating the security models when a high security process requests access to low security data files when multi-level security systems are in consideration. The difficulty of maintaining security integrity on a single host is now exasperated by the fact that the distributed trusted computing base (DTCB) has partitions that reside in each host; each security decision now has to take into consideration not only the host system state but also that of the servers. Also, the DTCBs have to ensure protection of the data during transmission, so the system now needs a cryptographic engine and the system administrators need to implement key management. Once the system is running, there is now a problem of data synchronization, especially when security classifications of objects are changed. SDOS attempted to answer these questions. Rassner, Kumar, Espinal Page 8
  9. 9. ECE 579S - September 2010 A 1989 analysis of the two most popular secure distributed systems, SDOS and TMach (Trusted Mach), showed that the accepted implementations both had similar systemic security issues. Mainly, the access control implementation in a distributed manner, and the fact that the network connections are inherently insecure posed the largest problems. The mandatory access control issues stem from the partitioning of the DTCB and the dynamic addition and deletions of hosts to the network both violate the Bell-LaPadula model and enable additional avenues of covert channels through multicast messages during this process. Security vulnerabilities are also introduced in where the access control checks are performed and the synchronization of the access control information across the network. Once computers and the Internet were available to the general public, security became a forefront issues since it directly impacted consumers and sales. In addition, now that the Internet is public, that meant exposure to hackers, enemy countries, anyone wishing to steal information or cause havoc. Commercial antivirus software, firewalls, secure systems became hot commodities. So, the systems which used to be safe in the hands of a limited number of university developers were now vulnerable and needed strong security to survive in the consumer market. The systems that originally hit the public internet in the early 90s look nothing like the “hardened” systems of today, with standard encryption and security features like SSL, TLS, IPSec, WPA2, and Kerberos to name a few. 3 Modern Computing Environments By the end of the 1990s there were many options for secure operating systems. FreeBSD, Linux, Solaris, HP-UX, among others, offered advanced user access control, encryption, network security, and many other features. But, were they sufficient to provide a solution to the questions posed by SDOS and Tmach? Had security finally caught up to utility since the days in the 60s and 70s when it was neglected in the university labs? In 1998, a team from the National Security Agency (NSA) analyzed the most secure systems of that time. While many of the systems provided a full suite of security features and there weren’t systemic issues as in the earlier secure distributed design, there were enough issues for the team to identify a set of “missing links” of security functionalities. Firstly, there was no commercially available kernel that provided mandatory access security as defined by the DoD. Those systems that did attempt to implement MAC mostly focused on the kernel and left the application space to be decided by the application developers. The NSA team recognized the need for a commercially viable solution that not only provided for mandatory access control in the kernel, but that also provided a uniform framework for trusted application, and the flexibility to adapt to complex security policies. Additionally, in mainstream systems, there were no provisions for trusted paths or protected paths. The trusted path is a mutually authenticated channel between processes, ensuring the data is protected and critical system functions are not being hijacked by an attacker. Additionally, mismanaged cryptographic tokens in the system were also analyzed to be a potential vulnerability. If the service or program requesting the token is not validated and authenticated, then there is no protection against the misuse of the cryptography and all the data encrypted as such will be compromised. Ultimately, the systems all incorporate the network, and while there is IPSec, SSL, and TLS to secure internet communications, they are not Rassner, Kumar, Espinal Page 9
  10. 10. ECE 579S - September 2010 invulnerable and the systems themselves are at risk to the weaknesses of the protocols they use to communicate across the network. The 1998 NSA analysis of the mainstream operating systems led to the definition of a new system architecture based on security – FLASK, the Flux Advanced Security Kernel, was intended to provide a flexible, standardized security architecture that addressed the vulnerabilities of the current systems and provided enough flexibility to be adapted to mainstream and future use. The following sections will review the FLASK architecture in detail and provide the implementation example of SELinux, the most security enhanced kernel to date. 4 Introducing Flask FLASK (Flux advanced Security Kernel) is an operating system security architecture that addresses the need of flexibility in security policies. Flask was developed to address three key security policy requirements. The three key flexibilities that were addressed are: controlling the propagation of access rights, enforcing fine grained access rights and supporting the revocation of previously granted access rights. This architecture was demonstrated by implementing a fluke Operating system micro-kernel. The micro-kernel clearly had a dividing line implemented between the policies and their implementation. It included a security policy server to make access control decisions. These decisions were enforced by the object server and a framework in microkernel. The need for microkernel architecture is not a requirement for implementing flask. The only requirement is to have a reference monitor in operating system. Linux successfully implemented these ideas in SELinux. Details of this implementation are described later in this paper. The concept of controlling propagation of access rights means that the policy is consulted on every access decision. This means that all requests for the access to objects are first checked against the policies defined in the system. The concept of fine grained access control is implemented by integrating the enforcement decisions into the service providing components of the system. In SELinux this idea is implemented by a three string security identifiers that include username, role and domain. This serves as fine grained access control implementation. The concept of revocation of the access rights is not easy to implement. When permission is revoked the system must ensure that access is not granted to the subject for that resource. This becomes especially challenging when revocation happens while a subject is in middle of accessing the object. SELinux checks permissions before the access is allowed. The new policy is enforced on later accesses. 4.1 Architecture of Flask The three key elements of flask architecture are a object manager, security server and Access Vector Cache (AVC). Object Manager is the enforcer of the security policy. Security server is responsible for making security decisions. Access vector cache is speeds up policy lookup decisions. Object Manager first consults the AVC for policy decisions and on a cache miss the request is directed to the security server. Besides security server the decision making subsystem may also include other administrative and policy database interfaces. Figure 4 below describes the key components of flask architecture. A Rassner, Kumar, Espinal Page 10
  11. 11. ECE 579S - September 2010 client makes a request to access an object. The request is handled by object manager. It sends the request to security server to get a policy decision for access. The response from the Security server is interpreted and enforced by the object Manager. Figure 4 - The Flask Architecture 4.1.1 Object Manager The object Manger in flask provides three primary interfaces for retrieving access, labeling and polyinstantiation decisions from a security server. When a subject tries to access an object, the access interfaces check if the permissions exist or not. Labeling interfaces allow assigning security attributes to an object. Polyinstantiation decision interfaces allow access to specific member of the instantiated set of resources. In SELinux, /tmp directory is accessible to all the processes and under that directory each process has a specific directory that it has full access to. This is a example of polyinstantiated set of resource (/tmp) and access to only a member of set ( /tmp/processid ). All Objects that are controlled by security policy have a label. Label describes the security attributes and is also called a security context. The security context is a policy independent data type and is represented as a variable length string. In SELinux the security context is implemented as “identity:role:domain” string. Identity is the user id and role and domain effectively provide the fine grained access to objects. Object manager treats the security context as a opaque identifier. To make the lookups efficient another policy independent data type called security identifier (SID) is used. It is a 32 bit number that provides mapping between SID and security context and is interpreted by security server. Figure 2 below shows the creation and labeling of a new object. A Client with specific SID called SID-C requests a new object to be created. The request is forwarded by Object manager to the Security Server. The Object manager passes the Client SID, SID of the related object (if any) and the object type. Security Server consults the policy logic to determine the security context for the new object. It returns the SID-O, the SID that corresponds to security context for this new object. Object manger binds this SID to the newly created Object. Rassner, Kumar, Espinal Page 11
  12. 12. ECE 579S - September 2010 Figure 5 - Labeling Operation by Object Manager Polyinstantiation support in object manager allows for sharing of fixed resources among multiple clients. The object manager partitions the clients into sets based on their SIDs. Object manager makes multiple copies of a resource to share among multiple processes. Each of these instances is called members. Figure 3 below shows that a request from client to access a polyinstantiated object. The clients SID (SID- C) is passed along with SID of the member object and the object type. Security manager consults the policy rules and returns the SID of the object that corresponds to the security context. The object manager then allows access to the member specific instantiation of resource. Rassner, Kumar, Espinal Page 12
  13. 13. ECE 579S - September 2010 Client (SID –C) Creates Client Object Object Manager Obj SID SID Poly Obj SID Obj SID Security Server Obj SID/ Context Map OBJ OBJ OBJ SID SID SID Mbr SID New SID Enforcement Mbr SID Req Policy Policy Logic ( SID,SID,Obj Type) Label Rules S Figure 6 - Polyinstantiation in Flask 4.1.2 Access Vector Cache When a subject makes a request to access an object, Object manager sends the request to Security Server to return the policy decision in terms of SID of the object. The process of computing the decision by Security server is fairly expensive. To speed up the access an “Access vector cache” notion was introduced. The decisions sent by Security server are cached in AVC in object manager for future reference. Once cache is populated and there is a cache hit, the decision is fairly quick and access to security server is avoided. 4.1.3 Security Server Security Server is a key component in flask architecture. It provides the policy decisions for object accesses by the subjects. It provides mapping from Security context to SID. It plays a crucial role in polyinstantiation support where it provides SIDs for member resources. It provides interfaces to load Rassner, Kumar, Espinal Page 13
  14. 14. ECE 579S - September 2010 and unload policies. The security server plays a central role in revocation of polices for a process. When a policy is revoked or updated, it notifies the object manager, which in turn updates its internal state. The AVC also intercepts the notification and updates or invalidates the cache for the policy that is revoked or updated. AVC then calls the registered entry points to begin the migration of the change to other system components. For example, when a file system would like to know when permission on a file object has been revoked. A registered callback notifies the affected file system (system components) of the change. Finally object manager sends a response to the Security server indicating that policy revocation or update is complete. 5 SELinux SELinux is a strong and flexible implementation of Flask on top of a Linux system. It provides means of implementing MAC and MLS, and more precisely, it implements a Bell-LaPadula access model. This is done by extending the Linux Security Modules extensions of the Linux Kernel, SELinux itself been integrated into the mainline 2.6 series of Linux Kernels. I is becoming a standard for trusted Linux deployments for current and future platforms (including Android [Shabial2010]). Some of its characteristics (originating from its implementation of Flask) include a separation of protection (enforcement) from security (policy). It also implements a reliable, trusted MAC/MLS model via trusted channels and type enforcement. SELinux provides mechanisms for the polyinstantiation of resources, and relies on extended attributes for implementing flexible security policies of variable granularity and role-based access control. Most importantly, it is backward compatible. That is, applications that run on a standard Linux distribution can run on a SELinux base without compilation (provided security policies are in place for it.) 5.1 Architecture SELinux being an implementation of Flask, it relies on security contexts for labeling of subjects and objects. Everything that can be a subject (namely a process) has a security context associated to it, and so does everything that can be accessed as a resource (namely via file handle). This is illustrated in Figure 7. Rassner, Kumar, Espinal Page 14
  15. 15. ECE 579S - September 2010 Figure 7 - Security Context usage in SELinux. In Figure 7, subjects requesting access to an object do so through the mediation of the Security Enforcement Module. This in turn enforces security policies when accessing objects on the subjects’ behalf. The Security Context of each participant (as well as the SIDs) is used as input for policy evaluation and enforcement. 5.1.1 LSM Architecture The LSM architecture (as presented in Figure 8 [Wright2002]) illustrates the role of LSM for the implementation of Flask architecture. After the standard DAC security evaluation takes place, a system call is intercepted by a LSM hook which consults a Policy Engine (a LSM Module) for allowing or denying the call to continue. What we can gather from this process is that 1. The active security model is the sum of the existing DAC and the security model(s) implemented by the policy engine, and 2. The security model(s) implemented by the later take precedence over DAC policies. Rassner, Kumar, Espinal Page 15
  16. 16. ECE 579S - September 2010 Figure 8 - LSM Architecture (High Level View) 5.1.2 Kernel and User Space On a SELinux system, a Flask object managers can run either in user space or in kernel space. On the other hand, security services run in kernel/privilege space at all times. As shown in Figure 9 [Caplan2007], user-space object managers mediate access to resources via a SELinux filesystem following the tradition of representing resources as files/file handles. The file system in turn runs within the LSM module and closely interacts with security server. Rassner, Kumar, Espinal Page 16
  17. 17. ECE 579S - September 2010 Figure 9 - Kernel view of a SELinux LSM Module Other object managers that reside within the kernel space must communicate with the security server via LSM hooks. Kernel-space object managers are expected to act accordingly. That is, they are trusted upon enforcing the access decisions computed by the security server. User-space object managers on the other hand, implicitly enforce access decisions by returning a file handle to a resource as returned by the SELinux filesystem (or an error if the resource is denied). In other words, enforcement of access decisions by user-space object managers actually takes place within the SELinux filesystem. In other words, enforcement always occurs in kernel space [Caplan2007]. 5.2 Capabilities SELinux capabilities extend to the implementation of extremely flexible security policies as well as mechanisms for implementing trusted Bell-LaPadula security models. These are presented next. 5.2.1 Policy Flexibility SELinux provides mechanism for flexible, variable granularity security policies by making use of file system extended attributes as security contexts. A SELinux system (0) enforces a specific format in Rassner, Kumar, Espinal Page 17
  18. 18. ECE 579S - September 2010 extended attributes so that they represent security contexts as security labels. These labels, though being policy-independent, are used as inputs during evaluation of security policies. Labels can be used for defining roles, category and sensitivity (need-to-know) labels than can be associated to both subjects (users and associated processes) and objects (any resource representable as a file handle.) A typical security context encoded in extended attributes might take the form of the user (or domain type label), role if any, type (when applied as an object label), and at least one category. The following is an example: user:role:type:sensitivity[:category,...][-sensitivity[:category,...]] Example 1 - Security context format as encoded in extended attributes When a category is missing, SELinux applies a default category according to the policy profile(s) in place. In this case, either explicitly or by a given policy profile; a missing category does not provide access by default. 5.2.2 Trusted MAC/MLS The usage of labels in a security context is a fundamental part in the implementation of a trusted mandatory access control and multi-level security model. For a trusted MAC/MLS to exist, SELinux provides mechanisms for trusted paths and type enforcement [Losccoco1998]. Trusted paths, an implementation of Flask client and server identification, are implemented at the IPC level. It ensures that no spoofing of user or server occurs. It guarantees an absence of tampering. Type enforcement is implemented in SELinux by providing mechanisms of least privilege. There is no access by default; there is no notion of super user or sticky bits as implemented in standard Unix implementations; and it gives precedence to MAC over DAC during security policy evaluation [Caplan2007]. With type enforcement, SELinux implements a state machine that governs trusted transitions from one operation to the next. A subject cannot perform an action on a object unless there is a relation, a transition, between the domain (the label associated to the subject) and the type of the object (the label associated to the object’s security context.) An example of this is found in 0. allow user_t bin_t : file {read execute getattr}; Example 2 - Associating a domain (user_t) to a type (bin_t) of file resources for read, execute and view of attributes. 5.3 Domain Transition At the core of type enforcement lays the mechanism of domain transition. Just as specified in Flask, a subject of a given domain should be able to replace its effective security context (and domain) when executing an operation on a type. A typical example is an unprivileged login process allowing a user to change its entry in /etc/shadow (a privileged resource.) Rassner, Kumar, Espinal Page 18
  19. 19. ECE 579S - September 2010 In typical UNIX systems, this is implemented by setting a sticky bit on the program performing the operation, in this case /usr/bin/passwd. The net effect is that the calling, unprivileged process creates a new process with the effective id of the passwd owner (in this case root). This elevation of access rights is illustrated in 0 [Caplan2007] Figure 10 - Elevation of access rights for changing an entry in /etc/shadow The problem with this approach is that it does not follow the principle of least privilege. The new executed process in step three (Figure 10) obtains the same access rights as root. An erroneous or malicious change on passwd would allow it to access anything root can. This is more than what is required, which is limited to access a single resource (/etc/shadow) for a very specific purpose (a password change.) With SELinux, type enforcement is used for achieving least privilege by enforcing state transitions defined a priori in the SELinux policy profiles. Rassner, Kumar, Espinal Page 19
  20. 20. ECE 579S - September 2010 Figure 11 - Elevation of access rights (limited to least privilege) via domain transitions. In Figure 11 [Caplan2007], a SELinux policy defines a set of state transitions which permit a process to change its domain to one limited for accessing the required resource and nothing more. In this example, the user as a domain user_t associated to its security context. Furthermore, its domain is first associated to the type associated to the /usr/bin/passwd program (in this case, passswd_exec_t). However (and not illustrated in the figure), passwd_exec_t cannot access the desire resource (/etc/shadow) unless it runs on a security context containing a specific passwd_t domain. A user requires a transition from its user_t domain into the passwd_t domain to carry this operation. This is achieved by second step of associating the passwd_t domain to the passwd_exec_t type as an entry point. The entry point is the association that permits the domain transition to take place. The last part of the required policy configuration is the association of the user domain (user_t) to the passwd_t domain. This mechanism enforces the types and domains associations as well as eliminates the need for running processes as root when accessing privilege resources. This, in combination with trusted paths previously mentioned are the mechanisms with which SELinux implements trusted MAC/MLS security models. 5.4 Additional Notes LSM is a partial implementation of Flask, and as a result, same limitations apply to SELinux (or any other implementation based on LSM architecture.) The most prominent feature missing is the ability to revoke access rights when a process is in progress. That is, a process cannot be aborted once its access rights are already revoked. This is a feature expected for implementation in the near future. Other LSM-based kernel modules exist for implementing Flask. Most notably are TOMOYO Linux (in the Linux Kernel mainline since 2.6.30); SMACK (Simplified Mandatory Access Control Kernel) and AppArmor Rassner, Kumar, Espinal Page 20
  21. 21. ECE 579S - September 2010 (available by default in Ubuntu distributions.) The main differences between these three additional LSM modules and SELinux are that their capabilities are path-based as opposed to label-based. Furthermore, SMACK and AppArmor purport to have easier policy configuration languages. SELinux still remains the most commonly deployed LSM implementation despite the complexity of its policy configurations. It remains to be seen whether it eventually adopts simpler policy configuration languages as done by the other existing LSM modules. Rassner, Kumar, Espinal Page 21
  22. 22. ECE 579S - September 2010 References [1] http://www.multicians.org/ [2] http://www.computerhistory.org/timeline/ [3] http://www.seas.upenn.edu/about-seas/eniac/operation.php [4] http://library.thinkquest.org/27887/gather/history/internet.shtml [5] P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303-314, Oct. 1998. [6] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau. The Flask Security Architecture: System Support for Diverse Security Policies. In Proceedings of the Eighth USENIX Security Symposium, pages 123-139, Aug. 1999. [7] A comparison of secure UNIX operating systems, Wong, R.M., Computer Security Applications Conference, 1990., Proceedings of the Sixth Annual (0-8186-2105-2) 1990. p.333-333 [8] Issues in secure distributed operating system design., Wong, Raymond M., Digest of Papers - IEEE Computer Society International Conference, Feb 1989. p.338-341 [9] Kain, R. Y. and Landwehr, C. E. 1987. On Access Checking in Capability-Based Systems. IEEE Trans. Softw. Eng. 13, 2 (Feb. 1987), 202-207. [10] Casey, T.A., Jr.; Vinter, S.T.; Weber, D.G.; Varadarajan, R.; Rosenthal, D.; , "A secure distributed operating system," Security and Privacy, 1988. Proceedings., 1988 IEEE Symposium on , vol., no., pp.27- 38, 18-21 Apr 1988 [11] Mike Accetta, Robert Baron, William Bolosky, David Golub, Richard Rashid, Avadis Tevanian, and Michael Young. Mach: A new kernel foundation for UNIX development. In Proceedings of the Summer 1986 USENIX Conference. pages 93-112. Atlanta, GA. June9-13. 1986. [12] Gregory, M. and Loscocco, P. (2007) 'Using the flask security architecture to facilitate risk adaptable access controls', Third Annual Security Enhanced Linux Symposium, National Information Assurance Research Laboratory, 14-15 March, Wyndham Hotel, Baltimore, MD, USA, [13] Red Hat Enterprise Linux 4: Red Hat SELinux Guide, http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter- 0013.html *14+ Jones, Tim. “Anatomy of Security-Enhanced Linux (SELinux),” http://www.ibm.com/developerworks/linux/library/l-selinux/ Rassner, Kumar, Espinal Page 22
  23. 23. ECE 579S - September 2010 [Shabial2010] Securing Android-Powered Mobile Devices Using SELinux. Asaf Shabial, Yuval Fledel and Yuval Elovigi, IEEE Computer and Reliability Societies, May/June 2010. [Wright2002] Wright et al “Linux Security Module Framework”, Usenix 2002. [Jones2008] Anatomy of Security-Enhanced Linux (SELinux) Architecture and implementation, M. Tim Jones, Consultant Engineer, Emulex Corp. 2008. http://www.ibm.com/developerworks/linux/library/l- selinux/ [Caplan2007] SELinux by Example, Caplan, MacMillan, Mayer. Prentice Hall, 2007 [Loscocco1998] The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. Loscocco et al. Usenix, 1998. Rassner, Kumar, Espinal Page 23

×