A System for Distributed SELinux Policy Management

A System for Distributed SELinux Policy Management Pedro Chavez Lugo, Juan Manuel Garcia Garcia, Juan J. Flores Div. de Est. de Postgrado, F. de Ing. Electrica Universidad Michoacana Morelia, Michoacan Email: [email protected], [email protected], [email protected] Abstract Access control in SELinux is designed for a monolithic operating system. In order to apply SELinux in distributed environments it is necessary to extend the policy specification language to include the notion of location. This paper presents a system that translates a location extended policy to local-policies. A policy server does this translation and distributes local policies to the corresponding hosts. The system implementation results are discussed.

Index Terms Access, control, distributed, SELinux, policies, Kerberos.

administration,

1. INTRODUCTION SELinux is a Linux kernel module designed by the National Security Agency (NSA), to enhance the access control mechanism through integration of the Discretionary Access Control (DAC), and the Mandatory Access Control (MAC) [1]. Access Control List (ACL) used by the discretionary access control [2], and Multilevel Security [3], Type Enforcement (TE) [4] [5] [6], Role-Based Access Control (RBAC) [7], and User Identity (UI) models are used by mandatory access control. SELinux kernel module is based on the Flux kernel advanced security (Flask), which is a flexible architecture that supports several mandatory policies. The Flask architecture was designed for microkernel environments but their use has spread to the Linux monolithic kernel to produce SELinux [8]. In this paper, we present a system for a distributed SELinux policy management to solve inconsistency in SELinux policies, which can be present in distributed

environments. We take a proposal of SELinux formal model [9] as a base to integrate the location concept in SELinux policies.

1.1. SELinux OPERATION In SELinux subjects and objects have a security context associated to them. A security context is formed by a set of attributes based on the mandatory access control models. The identity attribute is taken from the UI model, the domain and type attributes are taken from the TE model. The role attribute is taken from the RBAC model and the level attribute is taken from the MLS model. An example of security context is useru:systemr:systemt:s0, where the values useru, systemr, systemt, s0 correspond to identity, role, type, and level attributes, respectively. These concepts are defined as follows: Identity. Each user (subject) has an identity normally represented by the user name. Role. Within an organization a user can perform various activities, which are based on the tasks entrusted to it. The role attribute is used to classify the functions assigned to a user. Depending on the activities developed by a user, he/she can take one or more roles. The objects have associated only the object r role. Domain and Type. The processes or subjects are grouped into domains, and system resources (objects) are grouped into types. A domain can have access to a type for a restricted set of actions. Transitions may be allowed between domains. Level. The level attribute is used to define access control as follows: - A subject s can have access to an object o for a set of actions, if and only if the subject’s level s is greater than or equal to the object’s level o.

Transition

read access? Subject

I Identity

D Domain

T Type

DAC

read access?

allow

MAC R Role

L Level

deny

deny

allow

Object

Dominance

Figure 1. Interactions between attributes

Figure 3. Interaction between DAC and MAC

Policy Management Interface

User Space

Subject: spike

Kernel Space

read access (r)?

MAC

Allow

Security Context

SELinux Filesystem

Identity spike

Role systemr

Type systemt

Object: a.c Security Context

Level S1

Identity spike

Role object_r

Type testt

Deny

Various Kernel Object Managers

LSM Hooks

Access Vector Cache

Cache Miss Yes or No?

Security Server

Figure 4. Mandatory access control on SELinux

(Policy Rules and Access Desicion Logic)

SELinux LSM Module

Figure 2. SELinux module architecture

SELinux defines severals security classes of objects e.g. directory, file descriptor, file, file system, link, and process class. An access vector defines the access modes for each object class. Fig. 1 shows the relationships that exist between the different security attributes. A user with a given identity attribute can access one or more role attributes, a role attribute can access one or more domain attributes, and a domain attribute combined with a level attribute can have access to one or more type attributes with the same level value. Other important aspects are the dominance between roles and the transition between domains [5]. Fig. 2 shows the components of the SELinux module. An administrator, using an interface for policy management, sends a policy to the SELinux File System, which in turn sends the policy to the Security Server. The Security Server determines whether access to a resource is allowed or denied. The purpose of the access vector cache is to store the rules of the policy that are frequently evaluated to obtain a response as quickly as possible, avoiding using the security server repeatedly.

1.2. ACCESS CONTROL ON SELinux

When a subject tries to access an object to perform some action, the discretionary access control is the first requested instance. If the discretionary access control allows access to the object, then the mandatory access control is requested to allow or deny access to the object. If discretionary access control denies access to the object, then the mandatory access control is not invoked (see Fig. 3). Fig. 4 shows the interaction between subject and object by the mandatory access control. This access control type analyzes the subject and object security contexts. The subject has read access on the object a.c if and only if there is a rule that allows the systemt domain attribute to access the objects with the testt type attribute, and where the level attribute of the object is lower than subject’s level. Another access possibility exists if the systemr attribute role dominates a role that has enabled access to a domain attribute which can access to the testt type attribute, and the level criteria is satisfied. Another possibility to access an object may be given if the systemt domain attribute has permission to transition to a domain allowed to access the testt type attributes, and the level criteria is satisfied.

Level S0

Objects Classes Permissions

TE files

User statement

Constraints

RBAC files

Web server (wsl)

Security context

Mail server (msl)

DNS server (dnsl)

Data Base server (dbl)

DHCP server (dhcpl)

Internal network

Policy

Figure 5. SELinux local policy structure

1.3. SELinux POLICY

Figure 6. SELinux in distributed environment Nowadays, SELinux policies are administered locally and the policy rules are grouped in several directories, which contain a set of files. Fig. 5 shows the set of directories used to store local SELinux security policies. One directory is associated with a class, object, and permission structures defined by the Flask architecture. Similarly, two directories are associated with the rules, based on TE and RBAC models. The directory associated with RBAC rules is combined with the directory for the user statements. The constraints directory contains the set of rules that deny others. For example, if there is a rule that allows access, there may be a constraint invalidating such rule. The security context directory specifies to each element of files and directories. SELinux confines processes in sandboxes (i.e. a least privilege environment) to limit them to perform their specific functions. For example, the apache process can be confined into a domain to have access only to their resources (e.g. like configuration files and web pages). Then access control only allows the access to resources needed by the apache domain and denies the access to other resources. For the design and analysis of security policies, administrators must have experience with access control types and models. Another piece of knowledge administrators need to have for the design of SELinux policies is the macro preprocessor m4. For a good policy management, an administrator needs to know the correct configuration procedures. In SELinux distributed environments each host has a policy associated to it. Fig. 6 shows an example of a distributed environment of SELinux hosts, where each host is responsible for providing a network service. The administrative roles that can be exercised in such environment are cited in Table 1; Table 2 cites the roles that can be used in each host. Each host is associated with a set of users that can play one or more roles. Table 3 shows the users and roles for host dbl.

msl

wsl update

dnsl Policy Updated (consistency) None updated (inconsistency)

update

dbl

update

Policy changes (bkpr rules)

dhcpl

Figure 7. Manual SELinux policies update

If a set of rules for some policies change, and those changes are valid in a number of hosts, the policy administrator must update the policy in all hosts where those changes are valid (see Fig. 7). That is certainly not a desirable situation because the administrator may have not updated all hosts. The consistency, authenticity, integrity, availability, and confidentiality aspects must be present in the policy update process. For these reasons, it is necessary to develop tools that aid the systematization of the policy management process. In the next section we present an architecture that solves the problems addressed in this section.

2. Formal SELinux access control model and location concept We take as base a SELinux access control formal model and integrate the location concept to designate a host belonging in a SELinux distributed environment.

Table 1. Administrative roles

Role

Description

bkpr dbr dhcpr dnsr msr systemr wsr

Backup role Data base server admin DHCP server admin DNS server admin Mail server admin Operating system admin Web server admin

1) P(c) ← ∅ 2) for each rule of kind access vector (c, p1 , ..., pn ): • P (c) ← P (c) ∪ {(p1 , c),...,(pn , c)} A is the set of attributes that can be bound to subject domains or object types:

Hosts dbl x x

dhcpl x

dnsl x

C ← C ∪ {c}

An access vector defines the access modes for each object class. The set P(c) includes all the access modes for an object class c.

Table 2. Roles and hosts

Roles bkpr dbr dhcpr dnsr msr systemr wsr

•

msl x

wsl x

1) A ← ∅ 2) for each rule of kind attribute (a): • A ← A ∪ {a}

x x x

x

x x

x

x x

Table 3. Roles and users for dbl host

Users Roles bkpr, dbr, systemr dbr dhcpr dnsr msr systemr wsr

spike x x

x

john

bob x

x

T is the set of all domains for subjects and types for objects: 1) T ← ∅ 2) for each rule of kind type (t): • T ← T ∪ {t} 3) for each rule of kind type (t, a1 , ..., an ), • with a1 , ..., an ∈ A: T ← T ∪ {t} R is the set of all roles: 1) R ← {object r} 2) for each rule of kind role (r, t1 , ..., tn ): • R ← R ∪ {r} ↓D(r) is the set of roles dominated by r:

2.1. FORMAL MODEL FOR SELinux SELAC (SELinux Access Control) is a formal model proposed for the SELinux access control [9], it takes eleven configuration language constructs. The authors consider a relevant constructs selection to the accessibility problem of subjects to objects. An arbitrary SELinux configuration is used to obtain a collection of sets to determine whether a given subject can access a given object in a given mode. Basic sets for SELAC The set C includes all the objects class. • C ←∅ • for each rule of kind class (c): – C = {c} The set C includes all the objects class. 1) C ← ∅ 2) for each rule of kind class (c):

1) ↓D(r) ← ∅ 2) for each rule of kind dominance (i, j), • with r, j ∈ R: ↓D(r) ← ↓D(r) ∪ j U is the set of all users: 1) U ← ∅ 2) for each rule of kind user (u, r1 , ..., rm ), • U ← U ∪ u All possible security contexts, both for subjects and objects: O = {(u,r,t) | u ∈ U, r ∈ R, t ∈ T} The valid security contexts for subjects is denoted by the set S: S = {(u,r,t) ∈ O | u ∈ U, r ∈ R, t ∈ T}

The valid security contexts for objects class c: O(c) = {(u,objectr ,t) ∈ O | u ∈ U, t ∈ T} The TE access Matrix is associated to the set M (s), where s denotes a valid security context ∈ S for a subject. Constraints are associated to γ(s, o, p) function, ∆(s, c) function define the space of authorized permissions for a security context s, against a class c. Finally, when a given subj subject with a security context s try to obtain the a access on a given obj object of class c, first is necessary check for a given mode if the subj has the ability to access the obj directly. If it is not the case is necessary to verify a possible security context transition to grant or deny the a access for the obj object requested by a sub subject with security context s.

2.2. THE LOCATION ATTRIBUTE

EXTENDED

In the SELinux formal model cited previously we add the concept of location to designate a host integrated in a SELinux distributed environment. In the distributed environment we assign a hostname to every host. To integrate the location concept in SELinux policies we use two rule extensions to express relationships between users, roles, and locations. Rules involving locations and roles Syntax: location l roles r1 , r2 , ..., rn Semantics: location wsl roles { systemr, wsr, bkpr};. The

rules for locations and roles are expressed in the location statements module, these rules specify the set of roles that can be exercised in the locations.

1) R l ← {object r} 2) for each rule of kind location (l, r1 , ..., rn ), • with i = 1, ..., n : R l ← R l ∪ ri 3) for each r ∈ Rl the dominated role set ↓D(r), • R l ← R l ∪ ↓D(r) Tl is the set of the domains authorized for a role in location l: 1) Tl ← ∅ 2) for each rule of kind role (r, t1 , ..., tn ), • with i = 1, ..., n and r ∈ Rl : Tl ← Tl ∪ ti Ul is the set of the users for location l: 1) Ul ← ∅ 2) for each rule of kind user (u, l, r1 , ..., rm ), • with l ∈ L , r1 , ..., rm ∈ R l : Ul ← Ul ∪ u The space of valid security contexts for subjects on location l: Sl = {(u,r,t) ∈ O | u ∈ Ul , r ∈ Rl , t ∈ Tl } The valid security contexts for objects class c on location l: Ol (c) = {(u,objetcr ,t) ∈ O | u ∈ Ul , t ∈ Tl } Each location has a set for TE access Matrix Ml (s), constraints defined by γl (s, o, p) function, and the ∆l (s, c) function to define the space of authorized permissions for a security context.

3. ARCHITECTURE AND SYSTEM IMPLEMENTATION

Syntax: user u location l roles rx Semantics: user bob location wsl roles {bkpr};. The rules

To solve the problems generated by using SELinux in distributed environments, we propose an architecture that systematizes the policy management process. We first need to introduce location rules cited in section 2.2 and algorithms to produce local policies.

for users, locations and roles are expressed in the user statements directory. These rules specify the roles that a user may play in a given location.

3.1. ALGORITHMS TO PRODUCE LOCAL POLICIES

Rules for users, locations and roles

Sets for a location extended attribute L is the set of locations: 1) L ← ∅ 2) for each rule of kind location (l, r1 , ..., rn ), • L ← L ∪ l Each location contains a valid set of roles that users can play. R l is the set of the roles for location l:

The introduction of location policies require a modification in all SELinux policy mechanisms. Instead of modifying those mechanisms, which involve modifying the compiler, loader, and interpreter of access control policies, we allow administrators to introduce policies in the augmented syntax. Policies using the augmented syntax are stored in the policy server. When a host requires a policy, the server processes that rule, and send it to a host in the syntax required by SELinux. This mechanism allows hosts to ignore the location

Input: Set of files for Locations statements directory Output: Set of directories and files for host policies foreach rule (location l roles r1 , r2 , ..., rn ) do Create l directory with a local policy structure; foreach i = 1 to n do R l = R l ← R l ∪ ri ; end end

Algorithm 1: Location algorithm Input: Set of files for Locations directory Output: user - role rules foreach rule (user u location l roles r1 , ..., rm ) do if r1 , ..., rm ∈ R l then Append (Roles (user u) {r1 , ..., rm }) in users; end end

Web server (wsl)

Mail server (msl)

DNS server (dnsl)

Kerberos V server (ksl)

Data Base server (dbl)

DHCP server (dhcpl)

Internal network

Policy server (psl)

Figure 8. Proposed architecture for policy management

Algorithm 2: User algorithm

information managed by the policy server. If a policy does not allow a user to play a given role in a given host, a denial signal is sent, and no policy is issued to the host. On the other hand, if access is granted, the complete rule (in SELinux syntax) is sent to the location. The User and Location algorithms are used for producing local policies. For each rule for locations and roles, the locations algorithm generates a directory l, containing domains, file contexts, objects class and permissions, RBAC and TE directories, and the file for users statements. Similarly, the algorithm generates the set Rl , which defines the roles that can be played on location l. For each rule for users, roles, and locations, the User algorithm adds a new rule user u roles r1 , ..., rm in the user.local file contained in the l directory.

Objects Classes Permissions

TE files

Users statements

Constraints

Policy

RBAC files Security context

Locations statements

Policies segmentation

host_1 Objects Classes Permissions RBAC files

Constraints

TE files

Users statements

Security context

Policy_host_1

host_n Objects Classes Permissions RBAC files

Constraints

TE files

Users statements

Security context

Policy_host_n

Figure 9. Policy structure for locations

3.2. POLICY SERVER A host operates as policy server to update policy changes in all hosts associated with the changes. The policies must be available in the update process, a redundant policy sever is proposed to provide this characteristic. We achieve authenticity, integrity, and confidentiality in the policies update process by means of using Kerberos system. Fig. 8 shows the integration of the policy server and Kerberos system. The policy server centralizes the SELinux policies to avoid inconsistencies in the distributed environment when any rules change. This server reports to each host when the sets of policies it stores changes. At that point, a policy update process takes place. Fig. 9 shows that a centralized policy segmented and

distributed to the different hosts in the distributed environment. Policy assignment/update process When a host joins a distributed environment, it requires to identify itself in that environment. In the example shown in Fig. 8, the server responsible for providing the DHCP service assigns the following parameters needed for distributed operation: • • •

Network: ip, netmask, dns, dhcp, ntp. Kerberos server: Realm Name, Master, and Slave. Policy server: Master and Slave.

each host have also been implemented. Hosts deliver requests to policy server, receive the policies, and integrate them to the SELinux kernel module. dnsl

wsl

msl

4. CONCLUSIONS WORK

{Update} K wsl,psl {Update} K msl,psl

{Update} K dnsl,psl

{Update} K dhcpl,psl

{Update} K dbl,psl

dbl

psl

dhcpl

Figure 10. Update policy process

Once the client has obtained such parameters, it proceeds to interact with the Kerberos system to authenticate itself. For the service phase, the client sends a session key KC,S to the policy server, who will provide integrity, and confidentiality in the policy update process. In message 1 of the check consistency protocol (see Protocol 1), a client sends to the policy server a md5 value of its actual policy structure. The policy server compares the md5 value received and a md5 value obtained for the corresponding structure of the policy assignment to the client. If the two md5 values are equal, then the policy has not been changed; if they are different the client policy must be updated. C-Client, and S-Server 1. 2. 3. 4. 5.

C → S : {md5(policy)}KC,S If md5 values are equal then S → C : {Ok}KC,S else S → C : {Update}KC,S S → C : {Newpolicy}KC,S C → S : {Ok}KC,S

Protocol 1: Consistency check protocol. Update policy process When one or more policies change, the policy server is responsible for sending a message 3 to notify that policies need to be updated. Such notification is shown in Fig. 10. In this case is necessary analyze what to do with the active user sessions, considering the possibility of new rules that affected their activities. Security architecture implementation The policy server is fully implemented, delivering segmented policies to the hosts. Policies segmentation and Kerberos Implementation are ready. The clients on

AND

FUTURE

In this paper we address the policies inconsistency problem that SELinux presents in distributed environments. We propose an architecture for a distributed environment that comprises a centralized policy server to integrate and update policies on each host. On the policy update process the Kerberos V protocol provides authenticity, integrity, and confidentiality. The security policy server provides consistency on policies; availability is obtained with a redundant policy server. An interesting question is what to do when a policy is in use and it is necessary to update it. One solution is to block the system to give way to the update policy process, but the work of the users would be affected. Another solution to this problem is to inform users of the need of policy update, and give them a prudent time to log out and ensure that their activities are not affected. Several details like distinguishing between local or remote sessions, resource reservation, and time limits are desirable to include in the access control in order to improve it. Local or remote sessions The basic idea for distinguishing between local or remote sessions is to define trusted users and hosts. We consider necessary to define local or remote policies in distributed environments. But, the actual models, and access control implementations are deficient in this issue because local or remote sessions are not distinguished. As an example, Table 4 shows the different roles that user spike, can play in host B being located at host A. Misuse of resources In the present access control, what resources can be accessed by who can be specified but how many access can be done can not. For these reason is necessary include in the access control the resource reservation, to limit the resources misuse. Also, the time mark can be used to specify valid access times, and to exclude invalid access times. Another direction of work is to develop a policy server with heterogeneous operating systems.

Table 4. Roles for user spike From - To locations To From dbl dhcpl dnsl msl wsl

dbl bkpr dbr systemr bkpr bkpr bkpr bkpr dbr

dhcpl

dnsl

msl

bkpr

bkpr

bkpr

bkpr bkpr bkpr bkpr

bkpr bkpr bkpr bkpr

bkpr bkpr bkpr bkpr

wsl bkpr wsr bkpr bkpr bkpr systemr wsr

References [1] “Department of defense trusted computer system evaluation criteria,” Departament of Defense, DoD 5200.28STD, December 1985. [2] A. Grunbacher, “Posix access control lists on linux,” Suse Administration Guide, Tech. Rep., 2003. [3] D. E. Bell and L. LaPadula, “Secure computer systems: Mathematical foundations,” MITRE Technical Report 2547, Volume I, Tech. Rep., 1973. [4] W. E. Boebert and R. Kain, “A practical alternative to hierarchical integrity policies,” Proc. of the 8th National Computer Security Conference, Gaithersburg, MD, 1985. [5] L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat, “A domain and type enforcement unix prototype,” June 1995, unix Security Symposium Proceedings. [6] K. M. Walker, D. F. Sterne, M. L. Badger, M. J. Petkac, D. L. Sherman, and K. A. Oostendorp, “Confining root programs with type enforcement (dte),” 1996, sixth USENIX UNIX Security Symposium. [7] D. Ferraiolo and R. Khun, “Role-based access control,” 1992, proceedings 15th National Computer Security Conference. [8] P. Loscoco and S. Smalley, “Integrating flexible support for security policies into linux operating system,” proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference. [9] G. Zanin and L. V. Mancini, “Towards a formal model for security policies specification and validation in the selinux system,” June 2004, sACMAT 04 New York USA.