Lothlorien: Mandatory Access Control Using Linux Security Modules

Lothlorien: Mandatory Access Control Using Linux Security Modules Ashwin, Bharath M Palavalli, Harsha K, Shrisha Rao International Institute of Information Technology, Bangalore

Abstract— The concept of Mandatory Access Controls (MAC) forces a security policy on every user of a particular system. Linux provides Linux Security Modules (LSM) to develop such a framework. Lothlorien is a framework using LSM and the POSIX 1.e draft specifications1 Extended Attributes (EA) to implement MAC on Linux. Our new Lothlorien makes use of system call hooks provided by LSM to place checks on the access to system resources. The entire system is divided logically into different zones where the resources and users of the systems are distributed depending on their security context similar to a real organization. Along with the already available Discretionary Access Control (DAC) on Linux Lothlorien intends to achieve TCSEC B1 level of security. A policy will define the rules of access. Lothlorien ensures that the rules are followed under all circumstances. Separating all the entities of the system allows fine-grained access control. Index Terms— security, LSM, mandatory access, access control, Linux security

I. I NTRODUCTION The role of security in systems today is unquestionable. Security in the context of operating systems refers to information security within the system. Information security in the context of this paper refers to the control of access to information, within the system, by authorized users of the system. Operating systems provide the basis for any form of access to the system and a security layer at this level is seen as one of the initial steps for security of the system (Data Encryption may follow at the next level). Security is usually stated in terms of a set of norms or a framework describing what is acceptable behaviour of a system and what is not. Hence security is usually associated with a policy which is a set of rules describing acceptable behaviour of a system. The operating system has to ensure that given a policy, it is followed under all circumstances. This is called the mandatory access controls (MAC). Since system calls are the only way a user application can request for system resources, it is obvious that the system calls are modified to reflect the security framework. Modifications are minimal as only access control logic has to be inserted into the standard function of a system call. Linux provides Linux Security Modules (LSM) to insert such access control logic into the system calls by means of a call back function hook. Building a framework in this manner would allow us to take advantage of the security framework that is already in place in Linux. 1 IEEE

Std 1003.1e

Lothlorien implements MAC on Linux using the already available Discretionary Access Control (DAC) and the LSM framework. The various resources on the system is isolated from each other and from the users depending upon the security requirement. Logical containers are created to hold the various system resources. The users too are distributed among these zones to restrict their access to certain types of resources. The users of the system can be uniquely identified through their system wide unique user-id (UID). POSIX .1e standard specifies the concept of Extended Attributes (EA). Extended Attributes (EA) allows a user to specify a set of extra attributes to any file in the given (POSIX compliant) file system. These attributes are stored with the files like any default attributes such as creation date, modification time, etc. Lothlorien uses EA to store security information for every file in the system. Information about the container to which the file belongs to is stored with the file itself, thus avoiding a centralized structure maintaining this information. The exact set of tasks that a user can perform is decided by the security policy. A set of data structures maintains this information in the proc file system. This is done to isolate the data from the user space. There are three basic data structures storing information about the system. One of them stores information about the distribution of the users among the various containers. The other two structures store information about the set of tasks that each user is capable of running. The Linux security hooks are implemented to interrupt a system call and run a check for the requesting user and requested resource against the security policy. The hooks access the data structures to decide whether to allow or deny access. Lothlorien enforces security by checking every request for a resource against the security policy. The checks happen even when a user requests for the same resource again. Under no circumstances are the checks bypassed by any user. The LSM used do not modify the behaviour or the prototype of the system call. Hence, the programing model of Linux is not changed. This avoids modifications to older programs and no new constraints are specified to write new ones. II. S ECURITY Linux has provided security features which can be traced to the genesis of Unix systems. All Unix based systems have the concept of a superuser generally known as the root. This user has all the administrative powers to manage the system and all the other users generally need the super

user’s permission to perform actions. This provides a certain sense of security by restricting the scope of actions of a user and therefore limiting the damages that can be caused. This indicates that there can only be two types of users on a traditional Unix system, a super user and a normal user. The onus is on the super user to restrict unauthorized access by normal users. The privileges of overall system access and control is given exclusively to the super user. A. Discretionary Access Control Discretionary Access Control (DAC) is the traditional approach adopted by most Unix based systems. Security is enforced at the user’s discretion. The following are some of the highlights of this model: • The system consists of a set of users and a set of resources in form of files (or devices). • The users of the system belong to one or more user groups. The groups are not mutually exclusive. • Every file object is owned by a user. Usually this is the user who creates the file. • Each file object is associated with three sets of access rights. These sets are read, write and execute with each having three bits. • The owner of a file can set the access rights for users in his group. • The owner of a file can also determine the access rights for other users in the system (not in the owner’s group). • The owner of a file can also set the access rights for himself. • With three bits of access rights for each of the above entity, there are totally nine bits associated with a given file object. Practical systems demand a much more flexible method of specifying rules. DAC is not flexible enough to specify complex rules that a security model for an organisation may contain. Also as the name suggests the responsibility of securing information is on the owner or generally the user, of the system. A user can arbitrarily assign or transfer rights on objects to other users violating the check on information as per the security policy. Hence, the need for MAC. B. Mandatory Access Control Mandatory Access Control (MAC) is a set of rules for controlling access based directly on a comparison of the individual clearance (or authorization) for the information and the classification or sensitivity designation of the information being sought, and indirectly on considerations of physical and other environmental factors of control. The mandatory access control rules must accurately reflect the laws, regulations, and general policies from which they are derived. Mandatory access controls also take away the power from the root user as in traditional Unix based systems and subject all users, including administrators, to the access control policies of the system. MAC ensures that security protocols are followed and limit the damage in case of a compromise.

MAC policies are a characteristic of a given organisation. Therefore only the framework is usually provided leaving the actual policy to be stated by a organisation. The MAC also requires a set of DAC to be already present. C. Access Control Lists Linux supports Access Control Lists (ACL) where a user can exclusively define access controls for individual users. A user can specify access controls for a specific user or a group of users to any resource he owns. He can also deny access to individual users of a group while granting access to the group as a whole. However, ACL again requires the owner to define access permissions and hence forms a part of the DAC model. D. Extended Attributes Extended Attributes (EA) are a specification of the draft POSIX 1e standards. It allows for a file to be tagged with any set of attributes. The attributes are merely key value pairs of data. They are a general mechanism to identify various files and to store application specific meta data about them. EA provides various name spaces to store such data. One such name space called ’Security’ can be used to store meta data about security aspects related to that file. This feature is exploited by various security frameworks to specify policies at a very fine grain level. E. Linux Security Modules Linux Security Modules (LSM) was adopted into the Linux kernel from version 2.6.8. Any security system requires one to perform access control before the access to the resource is granted. Such access control logic has to be isolated from the normal user space. On Linux systems access controls are performed by embedding such code within the kernel and invoking the same when a system call is invoked. The access control code hence manages all accesses to a particular resource. LSM isolates the access control logic from the normal user space. It provides a set of callbacks for every available system call on the Linux system. This forces all requests for a given resource to undergo a security check. Any changes to the access control logic is immediately reflected in the next request. A security framework must make use of the callback to implement the access controls necessary. int open (char *filename, int flags);

0x80

long sys_open (dentry *filename,int flags);

long hook_sys_open (dentry *filename,int flags);

return;

Fig. 1.

A simple hook for the read system call.

III. R ELATED W ORK There is a lot of work related to implementing MAC on Linux involving various techniques to provide flexible policies. Security Enhanced Linux (SELinux) [1] is a project under the NSA 2 to implement MAC on Linux for military purposes. It follows the La Padula Model for its architecture and supports Rule Based Access Control(RBAC) as well. Since it is part of the Linux kernel portability issues are reduced. It uses EA to label files on the file system. It also supports security contexts for a given application. An application can switch its security context during its course of execution. The Simplified Mandatory Access Control Kernel (SMACK) project [2] uses LSM to implement MAC. It also uses the EA to label the files in the system. However it divides the system based on the four default labels. SMACK is currently supported in the Linux kernel. It does not explicitly divide the system into logical parts but builds slightly upon the existing modes of access i.e. read, write and execute and adds more modes of access such as append and combinations of the access as read, write etc. AppArmor is a MAC implementation for Linux also using LSM [3],[4]. However AppArmor dose not use EA for identifying files but uses the file paths instead. Similar to SMACK AppArmor allows read, write, link, file locking and file append accesses. AppArmor also defines rules for the various executable (individual or as a group) on the system. AppArmor also has a learning mode where a policy is generated automatically by looking at the various transactions going on in the system while running in this mode. It assigns ’profiles’ on a directory basis. It also specifies that a task or application can change its security context as and when required if it is authorized to do so. The application is said to change ’hats’. Rule Set Based Access Control (RSBAC) [5] is a project which is also inspired from the Bell’s La Padula Model for security. It specifies a security kernel [6]. It does not use the LSM completely but, instead implements its own hooks and focuses on the Role Based Access control [7], [8]. Similar projects to implement MAC exists in UNIX variants of operating systems as well. Trusted BSD project aims to implement MAC on the BSD variant of the UNIX operating system [9]. Hewlett-Packard uses the security containment application to implement MAC on its HPUX version of UNIX [10]. The Flexible Mandatory Access Control (FMAC) project is under development for the open source version of Solaris, Open Solaris project. IV. L OTHLORIEN Lothlorien is essentially an LSM which intends to achieve the following: • •

Implement MAC on a standard Linux System. Provide for a flexible policy mechanism.

2 NSA

: National Security Agency (USA)

Achieve at least TCSEC B1 level of security standards3 . Lothlorien is intended to be a base system upon which various models for security and hence, various policies will be tested. Lothlorien is intended to support all the basic primitives to allow such policies to be written and tested. The subsequent section will talk about the security model of Lothlorien. The architecture of Lothlorien is introduced in Section 5 and Section 6 contains example policies. •

Subject Object Request

Object Manager

Query

Policy Enforcement

Security Server

Security Policy Decision

Fig. 2.

Block diagram of a general security frameworka

a Source: The FLASK Security Architecture: System Support for Diverse Security Policies, pp. 123139.[11]

A. Security Model The Bell-La Padula model for security introduced the idea of Multi-Level Security (MLS) and the concepts of Objects and Subjects [12]. The Flux Advanced Security Kernel (FLUX) improved the model to implement flexible security policies and a formal architecture for implementing security [13]. The design of Lothlorien is influenced by both these projects and implements the same in its architecture. The following are the various entities in the Lothlorien security model. • Subject Any entity capable of making a request for a resource is classified as a subject. Subjects are all the users of the system. • Object All resources in the system form the set of objects. Objects consists of files, devices, memory, etc. • Role A role is a abstraction of the set of programs that a user is allowed to run. Example: a the role of a user who is able to run a ’user add’ , ’user delete’ programs may be assigned as a administrator. • Levels A logical division of the system. All subjects and objects belong to exactly one level. The logical divisions of the system are required by the TCSEC B1 standards.The logical sections (levels and categories, 3 Trusted Computer System Evaluation Criteria (TCSEC) is a set of norms that has to be met in order to certify that a given software is guaranteed to be secure for set of threats as specified by the ’Orange Book’ of the rainbow series. TCSEC is a organisation under the United States Government, Department of Defence (DoD)

•

described latter) represent different levels of security clearance as defined by the security policy. Categories A logical division of a level. All subjects and objects belong to exactly one category. (All subjects and objects belong exactly one level and one category, see Figure 3.

Levels

Lothlorien borrows elements from both LSM and FLASK (Figure 2). It uses the hooks that are provided by Linux. As Flask architecture proposes the presence of subjects and objects in the system, Lothlorien also categorizes all actors in the system as either objects or subjects. As directed by the TCSEC B1 standards, Lothlorien provides for up to 16 hierarchical levels and 60 categories for the users in the system. It also provides an editable policy. The system has been divided into a number of modules. A policy is scripted in order to setup the permissions for all users. The architecture is similar to Spencer et al. [11] and has been shown in Figure 4.

Categories

A. User List Fig. 3.

•

•

Levels and categories

Zone A zone is a pair of level and category. Since a given object (or a subject) can only belong to one level and one category, we can say that the particular object (or subject) belongs to a particular zone. Security policy The security policy is a set of rules that maps the set of users to the set of roles. It specifies which zone does a given subject or object belong to. It also specifies the roles with which a user can access the resource in a given zone.

The policy writer maps all programs with a set of suitable roles. Thus, roles are mutually exclusive subsets of a given set of programs in a system. A zone is a Cartesian product of the set of levels and the set of categories. The policy maps the set of subjects to the set of zones (this forms a onto or surjective function). Similarly, the policy maps all the objects in the system to the set of zones (this forms a onto or surjective function). Subjects can be associated with more than one role. However, they can only assume one of the roles while accessing a given resource. The policy writer also specifies which role should a subject assume while requesting access to the specific object. The set of programs that a subject can use is not a union of the roles. The concept of level and category allow the policy writer to specify a fine grained policy thus making the policy flexible.

Subject User Matrix

User Zone Matrix

Role Matrix Object

B. User Matrix This module is a matrix representation of the mapping between each user and a set of roles. The matrix represents what roles can a given user assume while accessing resources. The mapping is a surjective function of users and roles. This ensures that each user is mapped to at least one role. The exact set of roles that a user can assume is stated by the policy file. A user can execute a given action in his zone assuming different roles to produce possibly different results. C. User Zone Matrix

V. A RCHITECTURE

Silverlode

This module stores the zones and roles that a user belongs to. This file is necessary as the user is not represented as a file in Linux. The user is just a entry enumerated in the /etc/shadow file. All information pertaining to the user is stored in the shadow file. Since all users are subjects, additional information is to be stored about each subject. The user list module stores the zone and the appropriate roles associated with every user identified by his unique user id provided. The module is used to identify subjects using their uid and extract their respective zones and roles. The data is stored in the proc file system. The proc file system is isolated from the normal user space and hence is insulated from modifications by user programs. All the following files are stored in the proc file system for isolation form user space.

This module is a matrix describing to which zone does a user belongs to i.e. it describes the exact level and the exact category in the level to which a user belongs to. As described earlier the system is divided logically into 16 levels and 60 zones. i.e. there are 16 levels and each such level into 60 categories. A given category in a given level is referred to as a zone. All resources (files, devices,etc) belong to exactly one zone in the system. A user also belongs to exactly one zone in the system. This matrix is a characteristic of the policy file and the number of users in the system. D. Application List

Fig. 4.

Architecture of Lothlorien

This is a exhaustive list of all programs which have been given a privilege similar to a subject in the system. Each

application has a unique program number assigned by the policy writer. These applications are handled by the policy directly. If an application is not found in the list it is assigned a NULL role when it accesses objects the action for which is determined by the policy writer.

verification, the module loads all the matrices representing the policy. Algorithm 1 is pseudocode for the algorithm that SilverLode will follow in most cases (The algorithm will be changed for handling devices and other types of resources for which EA cannot be used directly)

E. Roles List

Algorithm 1 Checking policy when there is a request for a resource Require: A system call is invoked with the task name as ’invoked task’ and requesting a resource ’req resource’ 1: resource zone ← req resource EA 2: user zone ← user zone matrix 3: user role ← user matrix, role matrix 4: if user zone = resource zone then 5: if invoked task in user role then 6: make log entry 7: perform DAC checks 8: return 9: else 10: if user role = NULL then 11: perform NULL actions 12: make log entry 13: return 14: else 15: deny access 16: make log entry 17: return 18: end if 19: end if 20: else 21: deny access 22: make log entry 23: return 24: end if

This is a exhaustive list of all the roles defined in the system. The list contains the role name identified by a unique roll id. This list depends on the structure of an organisation and on the security policy being implemented. The role is an abstraction which is only used in the security context. The role defines the list of applications that a user can run. Policy

Role Matrix

Application List Role List Zones User Zone Matrix

User List

User Matrix

Fig. 5.

Contents of a policy

F. Role Matrix

H. Logger

This module represents the set of programs that a particular role is associated with. It represented as a matrix of role id and program numbers. The representation depends on the policy being implemented. Roles may have same or similar programs i.e. the intersection of roles need not be null. There is always a NULL Role defined for newly created applications or programs. The policy writer has to either add the new application to the Application List and modify the Role Matrix or else the application is access resources using the NULL Role. The procedure to handle a NULL role is specified by the policy writer.

The logger module captures messages from all modules. The data thus captured can be used to analyze policies or the system itself by means of playback.

G. SilverLode The main module that is responsible for the registration and launch of Lothlorien. The module uses the LSM hooks provided by POSIX.1e, extending the functionality of existing system calls with those of Lothlorien. It basically consists of functions to verify the credentials of the subject and then checks if the specified object can be accessed based on the clearance levels (see Figure 5) of the subject. Prior to any

VI. E XAMPLE S ECURITY P OLICIES Consider a system with three users as administrator, user1 and user2. The users are distributed among the different zones of the system with each user having a set of roles as shown in Table 1. The set of roles is maintained in the roles list as shown in Table 2. The set of users being mapped to specific roles is maintained in the user role matrix file as shown in Table 3. TABLE I The entries in the user zone file UID administrator user1 user2

Level:Category 0:1 10:55 12:40

Roles admin users, admin devices developer level 10, tester lead 55 developer level 12

TABLE II The entries in the roles list Role r1 r4 r6 r9 r11

Role Name admin users admin devices developer level 10 tester lead 55 developer level 12

Tasks user add, user remove, . . . mknod, . . . gcc, read, . . . junit, . . . suncc, read, . . .

TABLE III The entries in the user role matrix file UID administrator user1 user2

r1 X

r4 X

r6

r9

X

X

r11

Currently the policies are represented as a series of bit vectors. A flexible policy editor is to be developed. One of the other goals is to facilitate a smooth transition to Lothlorien. This would require one to handle files which may not have EA and hence cannot be identified by Lothlorien. Caching strategies would also be employed in order to improve performance. R EFERENCES

...

X

Consider a scenario where user1 attempts to run the mknod task. The algorithm will deny him access as mknod is not listed under any of the roles assigned to user1. He can only read certain files and can run the gcc task. Similarly the administrator cannot run the gcc task as it is not listed in any of the roles assigned to the administrator. VII. C ONCLUSION Lothlorien makes use of the features supported by standard Linux (LSM) and POSIX specifications (EA). This quality ensures that Lothlorien can be implemented on a wide variety of current systems. The support for a larger number of divisions allows the policy writer to specify complex policy and at the same time the use of simple data structures for maintaining policy information allows the easy traceability for a implemented policy. The policy related data structures are isolated from the user space for better security. Lothlorien allows one to experiment with various configurations for a policy. The isolation of users into different zones and restricting their actions with roles allows us to further expand the system to implement sub-policies. Each zone within the system can be associated with a sub-policy. Thus, subpolicies allow different zones to have different contexts for security. Policies reflect organisational structure. The designers of the organisational policies and that of the software policies are often different. There is a potential for a mismatch between the mapping of the interactions between entities in the organisation. Furthermore, the quality of the policy lies in its ability to detect violating interactions. Measuring the quality of the policy would involve enumerating all the possible interactions in an organisation. Since the problem is intractable, it is simplified by reducing the scale of the organisation into zones and studying the interactions between the zones. The major grouse against all security systems is the difficulty in building secure policies. Policies are the reference list for any form of secure access. A flaw in a policy could cause major loopholes in security itself which defeats the point of having a security system. It is hard to visualize and verify changes in the policy. Analysis based on zones will simplify visualization and development of security policies.

[1] P. Loscocco and S. Smalley, “Integrating Flexible Support for Security Policies into the Linux Operating System,” in Proc. Free and Open Source Software (FREENIX) Track: 2001 USENIX Annual Technical Conference (FREENIX ’01), June 2001. [2] C. Schaufler, “The Simplified Mandatory Access Control Kernel,” March 2008, the document is a whitepaper under development. [Online]. Available: http://www.schauflerca.com/data/SmackWhitePaper.pdf [3] Novell. (2007, October) Novell AppArmor (2.1) Quick Start. Novell. [Online]. Available: http://www.novell.com/documentation/apparmor/ [4] ——. (2007, September) Novell AppArmor Administrator Guide 2.1. Novell. [Online]. Available: http://www.novell.com/documentation/apparmor/ [5] M. Jawurek. (2005) RSBAC - a framework for enhanced Linux system security. Proc. conference seminar laboratory of Dependable Distributed Systems at RWTH Aachen University. RWTH-Aachen University, Aachen, Germany. [Online]. Available: http://www.rsbac.org/doc/media/rsbac-marek2006.pdf [6] A. Ott and S. Fischer-Hbner. The Rule Set Based Access Control (RSBAC) Framework for Linux. ISBN 9189422-63-5. Karlstad University Studies. [Online]. Available: http://www.rsbac.org/doc/media/rsbac-framework.pdf [7] A. Ott. (2001, November) The Rule Set Based Access Control (RSBAC) Linux Kernel Security Extension. 8th International Linux Kongress. Enschede. [Online]. Available: http://www.rsbac.org/doc/media/linux-kongress.pdf [8] ——. (2002, October) The Role Compatibility Security Model. Nordsec 2002, 7th Nordic Workshop on Secure IT Systems. Karlstad, Sweden. [Online]. Available: http://www.rsbac.org/doc/media/rcnordsec2002.pdf [9] R. Watson, B. Feldman, A. Migus, and C. Vance, “Design and Implementation of the TrustedBSD MAC Framework,” in Proc. Defense Advanced Research Projects Agency (DARPA) Information Survivability Conference and Exposition, April 2003, pp. 38–49. [10] HP-UX 11i Security Containment Administrator’s Guide, HP-UX 11i v2 ed., E0606, Hewlett-Packard, March 2007, Version B.11.23.02, Part Number 5991-8678. [Online]. Available: http://docs.hp.com/en/59918678/5991-8678.pdf [11] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau, “The FLASK Security Architecture: System Support for Diverse Security Policies,” in Proc. 8th USENIX Security Symposium, August 1999, pp. 123–139. [12] D. Bell and L. J. LaPadula, “Secure computer system: unified exposition and Multics interpretation,” MITRE, Tech. Rep. MITRE MTR2997, March 1976, available as NTIS AD-A023 588. [13] Secure Computer Corporation, “Assurance in the FLUKE Microkernel Formal Security Policy model,” Secure Computer Corporation, Contract MDA904-97-C-3047 CDRL SEQUENCE NO. A003, 1999. [14] 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 21st National Information Systems Security Conference, October 1998, pp. 303–314. [15] C. Wright, C. Cowan, S. Smalley, J. Morris, and G. Kroah-Hartman, “Linux Security Module Framework,” in Proc. Ottawa Linux Symposium, Ottawa, Ontario, Canada, June 2002, pp. 604–617. [16] M. Quaritsch and T. Winkler. (2006, April) Linux Security Modules Enhancements Module Stacking Framework and TCP State Transition Hooks for State-Driven NIDS. whitepaper. Graz University of Technology. Germany. [Online]. Available: http://whitepapers.zdnet.co.uk/0,1000000651,260277277p,00.htm [17] J. Morris. (2004, November) Filesystem Labeling in SELinux. [Online]. Available: http://www.linuxjournal.com/article/7689