Analyzing Integrity Protection in the Selinux Example Policy

Analyzing Integrity Protection in the SELinux Example Policy Trent Jaeger Reiner Sailer Xiaolan Zhang IBM T. J. Watson Research Center Hawthorne, NY 10532 USA Email: jaegert,sailer,cxzhang ¡ @us.ibm.com Abstract stallations). Recent efforts at MAC systems use flexible access control models to achieve convenient use (e.g., In this paper, we present an approach for analyzing DTOS, Flask [17, 21], etc.), but demonstrating that par- the integrity protection in the SELinux example policy. ticular security goals have been met is more difficult The SELinux example policy is intended as an exam- (and these systems have not been widely used either). ple from which administrators customize to create a pol- Flexible access control models typically result in more icy for their site’s security goals, but the complexity of complex policies, so it is more difficult to determine if the model and size of the policy make this quite com- these policies have the desired effect. plex. Our aim is to provide an access control model to express site security goals and resolve them against the The recent addition of the Linux Security Modules SELinux policy. Ultimately, we aim to define a mini- (LSM) framework [22] enables the MAC enforcement mal trusted computing base (TCB) that satisfies Clark- for the Linux kernel. The LSM framework is designed Wilson integrity, by first testing for the more restrictive to be agnostic to the MAC approach, and it has been de- Biba integrity policy and resolving conflicts using Clark- signed to support modules with flexible MAC models. Wilson semantics. Our policy analysis tool, Gokyo, im- The most comprehensive and flexible module for LSM plements the following approach: (1) it represents the is the SELinux module [18]. While SELinux supports SELinux example policy and our integrity goals; (2) it a variety of policy models itself, an extended Type En- identifies conflicts between them; (3) it estimates the res- forcement (TE) model [5] is used for most policy devel- olutions to these conflicts; and (4) provides information opment. An example policy is under development that for deciding upon a resolution. Using Gokyo, we de- consists of a set of UNIX service and application poli- rive a proposal for a minimal TCB for SELinux includes cies that each aim to ensure effective operation while 30 subject types, and we identify the work remaining preventing security vulnerabilities. The example policy to ensure that TCB is integrity-protected. Our analysis does not define a secure system, but serves as a basis for is performed on the SELinux example policy for Linux developing a secure system once the security goals are 2.4.19. defined. The extended TE model is rather complex (i.e., consists of a large number of concepts) and the SELinux example policy is large (e.g., 50,000+ policy statements in the policy.conf for Linux 2.4.19), so customiza- 1 Introduction tion of the SELinux example policy to a policy that guar- antees satisfaction of system security goals is an arduous and error-prone task. A goal for many years has been effective mandatory access control (MAC) for UNIX systems. By an effec- While the use of a simpler access control model might tive MAC system, we envision that system administra- make it easier to ensure that security goals are met, tors can define access control policies that guarantee site we believe that this would result in applications fail- security goals while enabling the convenient execution ing to run conveniently, and ultimately, the circumven- of applications. Early MAC policies, such as the Bell- tion of these security goals. The comprehensive na- LaPadula secrecy policy [2] and the Biba integrity pol- ture of the SELinux policy model enables flexible trade- icy [4], defined clear security goals, but were too restric- off between application and security goals. For exam- tive for convenient use for UNIX applications. Commer- ple, the SELinux example policy itself is developed by cial operating systems that were extended to meet Or- proposing application policies and refining them based ange Book B1 (i.e., MAC plus other features) were not on the policy violations that may be generated. Thus, broadly applied (i.e., mainly aimed at government in- the SELinux example policy itself is a direct result of we present related work, and we conclude in Section 6. making these trade-offs. The question is whether a manageable set of effective security goals can be described and verified for 2 SELinux Security Goals SELinux policies. Obviously, it is highly unlikely that the SELinux example policy adheres to a simple high- 2.1 SELinux Policy Model level policy, such as the two-level integrity model of LOMAC [9]. However, the policy may be sufficiently While SELinux supports a variety of access control pol- close to such a policy that the conflicts can be managed icy models [21], the main focus of SELinux policy de- (i.e., either a small number or a small number of equiv- velopment has been an extended Type Enforcement (TE) alence classes). If so, then verification may be possible model [1, 5, 20]. In this section, we provide a brief by verifying the general goals and using ad hoc tech- overview of the SELinux policy model concepts, focus- niques to resolve the conflicts. We have found that this ing only on the concepts that are relevant to the analysis approach holds some promise for application policies, that we perform. A number of other concepts are repre- in particular the Apache administrator [12], but do not sented in the SELinux extended TE model, such as roles know whether this can work for the trusted computing and identity descriptors, that we do not cover here. A de- base (TCB) subjects in the SELinux policy. Obviously, tailed description of the SELinux policy model is given if we cannot prove that the TCB is integrity-protected, elsewhere [20]. its system cannot be considered secure. The traditional TE model has subject types (e.g., pro- In this paper, we propose a near-minimal TCB for cesses) and object types (e.g., files, sockets, etc.), and ac- SELinux systems and examine how to verify that this cess control is represented by the permissions of the sub- TCB is integrity-protected. First, we define integrity ject types to the object types. In SELinux, the distinction relationships between the TCB subject types and less between subject and object types has been dropped, so trusted system and application subject types. Second, there is only one set of types that are object types and we input these constraints into our policy analysis tool, may also act as subject types. called Gokyo [12], and identify integrity conflicts between the TCB and the system. The Gokyo tool enables The SELinux extended TE model is shown in Figure 1. flexible expression of conflict sets and their resolution, All objects are labeled with a type. All objects are an in- so our next goal is to determine what resolutions appear stance of a particular class (i.e., data type) which has its feasible for TCB integrity conflicts. Using Gokyo, we own set of operations. A permission associates a type, a classify conflicts into classes based on their likely res- class, and an operation set (a subset of the class’s opera- olution. Since most resolutions depend on ad hoc in- tions). Thus, permissions associated with SELinux types formation, it is still a manual process to complete the can be applied independently to different classes. For analysis. Using Gokyo, we identify a minimal TCB for example, different rights can be granted to a user’s files the SELinux example policy of 30 subject types, half of than to their directories. In fact, since the objects are of which are infrequently-used administration subjects. To different classes, they have different operations. Should use this TCB, 5 sanitization problems must be solved, the administrator want to give different access rights to but we believe that most can be addressed in practice, two objects of the same class, then these objects must including the use of Gokyo itself to manage the broad belong to different types. file access rights currently granted to trusted subjects. Ultimately, Gokyo is useful in identifying problems in Permission for a (subject) type to perform operations on meeting security goals, classifying these problems, and a(n) (object) type are granted by the allow statement. providing information for resolving them. Any element of the permission relationship can be ex- pressed using this statement, so the expression of least The paper is structured as follows. In Section 2, we ex- privilege rights is possible. The dontaudit statement pro- amine the SELinux extended Type Enforcement model vides a variation on the basic permission assignment. and outline our site security goals for that model, in- A combination of allow statements result in a union of tegrity protection of a minimal trusted computing base. the rights specified, whereas a combination of dontau- In Section 3 we describe our approach to resolving a pol- dit statements on the same type pair and class are inter- icy against our integrity protection requirements. In Sec- sected. tion 4, we detail the implementation of our analysis using Gokyo and present our analysis results. In Section 5, In addition, the extended TE model also has type at- (Object) label Type Object auditallow or allow (union) (Subject) instance-of Class Permission Type dontaudit(intersection) Operation Set Figure 1: SELinux extended Type Enforcement (TE) policy model basics. tributes that represent a set of types (i.e., all the types SELinux extended TE model also includes a large num- with that attribute assigned).

Load more