maintaining the correctness of the linux security modules ... · maintaining the correctness of the...

Maintaining the Correctness of the Linux SecurityModules Framework

Trent Jaeger Xiaolan Zhang Antony EdwardsIBM T. J. Watson Research Center

Hawthorne, NY 10532 USAEmail: {jaegert,cxzhang}@us.ibm.com

Abstract

In this paper, we present an approach, sup-ported by software tools, for maintaining thecorrectness of the Linux Security Modules(LSM) framework (the LSM community isaiming for inclusion in Linux 2.5). The LSMframework consists of a set of function callhooks placed at locations in the Linux kernelthat enable greater control of user-level pro-cesses’ use of kernel functionality, such as isnecessary to enforce mandatory access control.However, the placement of LSM hooks withinthe kernel means that kernel modifications mayinadvertently introduce security holes. Funda-mentally, our approach consists of complemen-tary static and runtime analysis; runtime anal-ysis determines the authorization requirementsand static analysis verifies these requirementsacross the entire kernel source. Initially, the fo-cus has been on finding and fixing LSM errors,but now we examine how such an approachmay be used by kernel development commu-nity to maintain the correctness of the LSMframework. We find that much of the verifica-tion process can be automated, regression test-ing across kernel versions can be made resilientto several types of changes, such as source linenumbers, but reduction of false positives re-mains a key issue.

1 Introduction

The Linux Security Modules (LSM) projectaims to provide a generic framework fromwhich a wide variety of authorization mech-anisms and policies can be enforced. Sucha framework would enable developers to im-plement authorization modules of their choos-ing for the Linux kernel. System administra-tors can then select the module that best en-forces their system’s security policy. For exam-ple, modules that implement mandatory accesscontrol (MAC) policies to enable containmentof compromised system services are under de-velopment.

The LSM framework is a set of authorizationhooks (i.e., generic function pointers) insertedinto the Linux kernel. These hooks define thetypes of authorizations that a module can en-force and their locations. Placing the hooks inthe kernel itself rather than at the system callboundary has security and performance advan-tages. First, placing hooks where the opera-tions are implemented ensures that the autho-rized objects are the only ones used. For ex-ample, system call interposition is susceptibleto time-of-check-to-time-of-use (TOCTTOU)attacks [2], where another object is swappedfor the authorized object after authorization,because the kernel does not necessarily usethe object authorized by interposition. Sec-

Ottawa Linux Symposium 2002 224

ond, since the authorizations are at the point ofthe operation, there is no need to redundantlytransform system call arguments to kernel ob-jects.

While placing the authorization hooks in thekernel can improve security, it is more difficultto determine whether the hooks mediate andauthorize all controlled operations. The systemcall interface is a nice mediation point becauseall the kernel’s controlled operations (i.e., oper-ations that access security-sensitive data)musteventually go through this interface. Insidethe kernel, there is no obvious analogue forthe system call interface. Any kernel functioncan contain accesses to one or more security-sensitive data structures. Thus, any mediationinterface is at a lower-level of abstraction (e.g.,inode member access). Also, it is necessaryto link these operations with their access con-trol policy (e.g., write data) to ensure that thecorrect authorizations are made for each con-trolled operation. If there is a mismatch be-tween the policy enforced and the controlledoperations that are executed under that policy,unauthorized operations can be executed. Webelieve that manual verification of the correctauthorization of a low-level mediation inter-face is impractical.

We have examined both static and runtimeanalysis techniques for verifying LSM autho-rization hook placement [6, 20]. Our staticanalysis approach identifies kernel variables ofkey data types (e.g., inodes, tasks, sockets, etc.)that are accessed prior to authorization. Theadvantage of static analysis is that its com-plete coverage of execution paths (both dataand control) enables it to find potential errorsmore easily. Many successes with static anal-ysis have been reported recently [7, 11, 16].The effectiveness of static analysis is limitedby the manual effort required for annotationand the number of false positives that are gen-

erated1. Also, some tasks are very difficult forstatic analysis. However, runtime analysis re-quires benchmarks that provide sufficient cov-erage and also creates false positives that mustbe managed. Thus far, our experience has beenthat runtime analysis provides a useful comple-ment for static analysis, so both types of anal-yses need to be performed to obtain effectiveverification.

While our initial results have been positive2,ultimately, we believe that it is necessary thatsuch analysis become part of the kernel de-velopment process to really maintain the ef-fectiveness of the LSM framework. As theLinux kernel is modified, the LSM authoriza-tion hooks may become misplaced. That is,some security-sensitive operations that werepreviously executed only after authorizationmay now become accessible without proper au-thorization. Since the subtleties of authoriza-tion may be non-trivial, the kernel developersneed a tool that enables them to verify that theauthorization hooks protect the system as theydid before or identify the cases that need ex-amination. Further, kernel developers need away of communicating changes that need to beexamined by the LSM community.

In this paper, we outline the analysis capabil-ities of our static and runtime tools and de-scribe how they are used together to performLSM verification. We do not provide a detaileddiscussion of the analysis tools, so interestedreaders are directed elsewhere for that infor-mation [6, 20]. We would also like to makesuch tools available and practical for the ker-nel development community, so we examinehow effectively the analysis steps can be au-tomated and what issues the users of the analy-

1Static analysis is overly conservative because someimpossible paths are considered which can lead to somefalse positives.

2Five LSM authorization hooks have been added orrevised due to the results of our analysis tools.


sis tools must resolve in order to complete theanalysis. We find that much of the verificationprocess can be automated, regression testingacross kernel versions can be made resilient tominor changes, such as source line numbers,but reduction of false positives remains a keyissue. While the analysis tools are not yet avail-able as open source, we are working to obtainsuch approval.

The remainder of the paper is structured as fol-lows. In Section 2, we review the goals and sta-tus of the LSM project. In Section 3, we definethe general hook placement problem. In Sec-tion 4, we review the static and runtime anal-ysis verification approaches. In Section 5, weoutline how LSM verification experts use thestatic and runtime analysis tools in a comple-mentary fashion to perform a complete LSMverification. In Section 6, we examine how theanalysis tools can be made practical for use bythe kernel development community. In Sec-tion 7, we conclude and describe future work.

2 Linux Security Modules

The Linux Security Modules (LSM) frame-work is being developed to address insuffi-ciencies in traditional UNIX security. Histor-ically, UNIX operating systems provide a sin-gle authorization mechanism and policy modelfor controlling file system access. This ap-proach has been found to be lacking for a va-riety of reasons, and these inadequacies havebeen exacerbated by emerging technologies.First, the UNIX policy model lacks the ex-pressive power necessary for some security re-quirements. UNIX file mode bits enable con-trol of file accesses based on three types of re-lationships that the subject may have with thefile: file owner, file group owner, and others.Some reasonable access control combinationscannot be expressed using this approach, so ex-tension have been created (e.g., access control

lists (ACL)). Second, the UNIX access con-trol model provides discretionary access con-trol (DAC) whereby the owner of the objectscontrols the distribution of access. Thus, userscan accidentally give away rights that they didnot intend, and the all-powerful userroot, aswhich a wide variety of diverse programs run,can change access control policy in the systemarbitrarily. Third, with the advent of new pro-gramming paradigms, such as mobile code, theUNIX assumption that every one of the users’processes should always have all of the users’rights became flawed [3], and it was found thatthe UNIX access control model was too lim-ited to enable the necessary level of flexibil-ity [10, 1, 9]. Fourth, controlling access to avariety of other objects besides files was alsofound to be necessary, and, in some cases, re-stricting the relationships that objects may en-ter is necessary [17]. For example, the abilityto mount one file system on another is a con-trolled operation on the establishment of thatrelationship between the two file systems.

Initially, the authorization mechanisms pro-posed to address these limitations were in-serted at the user-system boundary (e.g., bywrapping system calls [1] or callbacks [9]). Bynot integrating the authorization mechanismswithin the kernel, the authorization mechanismlacks the kernel state at the time that the oper-ation is performed. Attacks have been foundthat can take advantage of the interval betweenthe time of the authorization and the time atwhich the operation is invoked [2]. Further,the performance of the system is degraded be-cause the kernel state must be computed twiceif the authorization mechanism is placed at thesystem call interface. Recent research work onimproving the UNIX authorization mechanismin Linux has focused on inserting hooks tothe authorization mechanism in the kernel di-rectly [4, 13, 14, 15, 18]. However, the varietyof authorization hook placements and styles re-sulted in ad hoc modifications to the Linux ker-


nel.

Another major advancement has been the sep-aration between the authorization mechanismand the policy model used. The work onDTOS and Flask security architectures demon-strated how the authorization policy server canbe separated from the authorization mecha-nism [12, 17]. Thus, a variety of access controlpolicies can be supported. In particular, a va-riety of mandatory access control (MAC) poli-cies can be explored. An advantage of MACpolicies is that provable containment of overtprocess actions is possible, so protection of theTCB and key applications can be implemented.Various flavors of MAC policy models havebeen examined, but no one approach has beenshown to be superior. The design of effectivepolicy models and policies themselves remainsan open research issue.

The LSM project includes several of the par-ties working on independent Linux kernel au-thorization mechanisms, in particular Security-Enhanced Linux (SELinux) and Immunix Sub-Domain, to create a generic framework for call-ing authorization modules from within the ker-nel. Motivation to unite these mechanismscame when Linus Torvalds outlined his goalsfor such a framework [19]. Linus stated thathe wants authorization to be implemented bya module accessible via generic hooks. Thehope that an acceptable authorization frame-work would be integrated with the mainlineLinux kernel has resulted in a comprehensiveLSM implementation.

As of Linux 2.4.16, LSM consists of 216 au-thorization hooks inserted in the kernel that cancall 153 distinct authorization functions de-fined by the authorization modules (i.e., load-able kernel modules). The authorization hooksenable authorization of a wide variety of op-erations, including operations on files, inodes,sockets, IPC messages, IPC message queues,

semaphores, tasks, modules, skbuffs, devices,and various global kernel variables. Authoriza-tion modules for SELinux, SubDomain, andOpenWALL have been built for LSM, so LSMis capable of enforcing MAC policies already.

3 General Hook Placement Prob-lems

3.1 Concepts

We identify the following key concepts in theconstruction of an authorization framework:

• Authorization Hooks: These are the au-thorization checks in the system (e.g., theLSM-patched Linux kernel).

• Policy Operations: These are the oper-ations for which authorization policy isdefined in the authorization hooks. Be-cause we would like to identify code thatis representative of the policy operation,they are practically defined as the firstcontrolled operation (see below) requiringthis policy.

• Security-sensitive Operations: Theseare the operations that impact the securityof the system.

• Controlled Operations: A subset ofsecurity-sensitive operations that mediateaccess to all other security-sensitive oper-ations. These operations define amedia-tion interface.

The definition of these concepts is made clearby a comparison between system call media-tion and the in-kernel mediation used by LSMshown in Figure 1. When authorization hooksare placed at the system call interface, the pol-icy operations (e.g., the conceptual operation


S SSS S S

H: Authorization HookP: Policy OperationC: Controlled OperationS: Security-sensitive Operation

Syscall Trap

Kernel

...

User

System Call Approach LSM Approach

...

......

C C

H

P/C

P

H

Figure 1:Comparison of concepts between system call interposition framework and LSM.

write ) and controlled operations (e.g., wheremediation of all file opens for write access oc-cur at the system callsys_open with the ac-cess flagWRONLY) are effectively the same.This is because policy is specified at the sys-tem call interface, and the system call inter-face also provides complete mediation. Thesecurity-sensitive operations in both cases arethe data accesses made to security-relevant ker-nel data, such as files, inodes, mappings, andpages.

When authorization hooks are inserted in thekernel, the level of complete mediation is thekernel source code, so the policy operationsand controlled operations are no longer nec-essarily the same. For example, rather thanverifying file open for write access at the sys-tem call interface, the LSM authorizations fordirectory (exec), link (follow link), and ulti-mately, the file open are performed at the timethese operations are to be done. This elimi-nates susceptibility to TOCTTOU attacks [2]and redundant processing. The kernel sourceis complex, however, so it is no longer clearthat all security-sensitive operations are actu-ally authorized properly before they are run.

Given the breadth and variety of security-sensitive operations, we would like to iden-tify a higher-level interface for verifying theirproper LSM authorization. This interfacemust mediate all access from the authorizationhooks to the security-sensitive operation. Thisinterface is referred to as themediation inter-faceand is defined by a set of controlled oper-ations.

3.2 Relationships to Verify

Figure 2 shows the relationships between theconcepts.

1. Identify Controlled Operations: Findthe set of operations that define a medi-ation interface through which all security-sensitive operations are accessed.

2. Determine Authorization Require-ments: For each controlled operation,identify the policy operations that mustbe authorized by the LSM hooks.

3. Verify Complete Authorization: Foreach controlled operation, verify thatthe policy operations (i.e., authorization


requirements) are authorized by LSMhooks.

4. Verify Hook Placement Clarity: Pol-icy operations should be easily identifi-able from their authorization hooks. Oth-erwise, even trivial changes to the sourcemay render the hook inoperable.

The basic idea is that we identify the con-trolled operations and their authorization re-quirements, then we verify that the authoriza-tion hooks mediate those controlled operationsproperly. This verifies, that the LSM hookplacement is correct with respect to this setof controlled operations and authorization re-quirements. When the mediation interface isshown to be correct, it verifies LSM hookplacement with respect to all security-sensitiveoperations. These tasks are complex, so it isobvious that automated tools are necessary.

Controlled Operation

Security-sensitive Operation

Mediates

Mediates

1

2

3

4

Authorization Hook

Predicts

Policy Operation

Comprises

Figure 2: Relationships between the authorizationconcepts. The verification problems are to: (1) iden-tify controlled operations; (2) determine authorizationrequirements; (3) verify complete authorization; and (4)verify hook placement clarity.

In addition, we found that additional auto-mated support is necessary to identify the con-trolled operations and their authorization re-quirements. First, manual identification of the

controlled operations is a tedious task. Wemust develop an approach by which controlledoperations can be selected from the set ofsecurity-sensitive operations. Once this ap-proach has been determined automated tech-niques are needed to extracted these operationsfrom the kernel source. Second, because thecontrolled operations are at a lower level thanthe policy operations, we need to determine thepolicy operations (i.e., authorization require-ments) for a controlled operation. Since weexpect a large number of controlled operations,it is necessary to develop an approach to sim-plify the means for identifying their authoriza-tion requirements.

Lastly, to ensure maintainability of the autho-rization hooks we can verify that the policy op-erations can be easily determined from the au-thorization hook locations. This work is hasbeen done, but in interest of focus it is outsidethe scope of this paper. This is work is pre-sented elsewhere [6].

3.3 Related Work

We are not aware of any tools that perform anyof the tasks outlined above. While static analy-sis has had some promising results lately [7,11, 16], the problems upon which they havebeen applied have been different and narrowerin scope (e.g., buffer overflow detection). Webelieve that static analysis tools will eventuallyprovide some important improvements in theverifications described above, but some analy-ses will be easier to do with runtime tools (e.g.,due to reduced specification for comprehensivetests).

4 Solution Background

In this section, we review the approaches wedevised for using static and runtime analysisto verify the placement of LSM authorization


hooks.

4.1 CQUAL Static Analysis

We use the CQUAL type-based static analy-sis tool as the basis for our static analysis [8].CQUAL supports user-definedtype qualifiersthat are used in the same way as the standard Ctype qualifiers such asconst . We define twotype qualifiers,checked and unchecked .The idea is that a variable with auncheckedqualifier cannot be used when a variable with achecked qualifier is expected. This simulatesthe need to authorize variables before they areused in controlled operations.

The following code segment demonstrates thetype of violation we want to detect. Functionfunc_a expects achecked file pointer as itsparameter, but the parameter passed is of typeunchecked file pointer.

void func_a(struct file*checked filp);

void func_b( void ){

struct file * unchecked filp;...func_a(filp);...

}

As input to CQUAL, we define type rela-tions between thechecked anduncheckedtype qualifiers that represent the requirementthat a checked type cannot be used whenan unchecked is expected. Using its infer-ence rules, CQUAL performsqualifier infer-enceto detect violations against these type re-lations. These violations are calledtype errors.CQUAL reports both the variables involved inthe type errors and the shortest paths to typeerror creation for these variables. For a moredetailed description of CQUAL, please refer tothe original paper on CQUAL [8].

In order to do this analysis, CQUAL requiresthat the target source be annotated with the typequalifiers. This is an arduous and error-pronetask for a program like the Linux kernel, so weuse GCC analysis to automate the annotationprocess. There are three GCC analyses we per-form to prepare the source code for CQUALprocessing.

1. All controlled object must be initialized tounchecked .

2. All function parameters that are used ina controlled operation must be marked aschecked .

3. Authorizations must upgrade the autho-rized object’s qualified type tochecked .

In order to ensure that static analysis is sound(i.e., no type errors are missed by the analy-sis), we perform some additional GCC analy-ses. For example, we verify no reassignmentsof variables and check for intra-procedural typeerrors. These analyses are sometimes primi-tive, but they have limited the amount of man-ual work required sufficiently. We are work-ing with the CQUAL community and others toimprove the effectiveness of static analysis forthis purpose. For a more detailed descriptionof our static analysis, see our paper [20].

With our static analysis, we have identifiedsome LSM vulnerabilities in Linux 2.4.9, butsince the runtime analysis tool was done firstwe have found only one new, exploitable vul-nerability. It has since been fixed in later ver-sions of LSM [5]. Figure 3 shows the vulnera-bility.

The code fragment demonstrates a time-of-check-to-time-of-use [2] (TOCTTOU) vulner-ability. In this case, thefilp variable is au-thorized insys_fcntl . However, a new ver-sion offilp is extracted from the file descrip-tor and used in the functionfcntl_getlk .


Since a user process can modify its mappingbetween its file descriptors and the files theyreference this error is exploitable.

4.2 Vali Runtime Analysis

We have developed a tool, called Vali3, forcollecting key kernel runtime events (Vali run-time) and analyzing this runtime data (Valianalysis) to determine whether LSM authoriza-tion hooks are correctly placed [6]. The keyinsight of the Vali analysis is that most of theLSM authorization hooks are correctly placed,so it is anomalies in the authorization resultsthat enables us to identify errors. Using thisapproach, we have found 5 significant anoma-lies in LSM authorization hook placement, 4 ofwhich have been identified as bugs and fixed.

Vali consists of kernel instrumentation tools,kernel data collection modules, and data anal-ysis tools. The kernel instrumentation toolsbuild a Linux kernel for which kernel events(e.g., system calls and interrupts), function en-try/exits, LSM authorizations, and controlledoperations can be logged by the data collectionmodules. We use the same kind of GCC analy-sis as we did for the static analysis to find con-trolled operations in the kernel. Other eventsare easily instrumented through GCC instru-mentation (functions), breakpoints on entry ad-dresses (kernel events), and the LSM autho-rization hooks themselves (authorizations).

Loadable kernel modules for each type of in-strumentation collect these events. The mainproblem with data collection is not the perfor-mance overhead, but the data collection band-width. The performance overhead of instru-mentation is only about 10%, and since theanalysis kernel is not a production kernel thisis quite acceptable. However, the rate at whichdata is generated can exceed the disk through-

3Vali is the Norse God of Justice and the first fourletters in “Validate.”

/* from fs/fcntl.c */long sys_fcntl(unsigned int fd,

unsigned int cmd,unsigned long arg)

{struct file * filp;...filp = fget(fd);...err = security_ops->file_ops

->fcntl(filp, cmd, arg);...err = do_fcntl(fd, cmd, arg,

filp);...

}static longdo_fcntl(unsigned int fd,

unsigned int cmd,unsigned long arg,struct file * filp) {

...switch(cmd){

...case F_SETLK:

err = fcntl_setlk(fd, ...);...

}...

}/* from fs/locks.c */fcntl_getlk(fd, ...) {

struct file * filp;...filp = fget(fd);/* operate on filp */...

}

Figure 3: Code path from Linux 2.4.9 contain-ing an exploitable type error.


# open for read access

1 = (+,id_type,CONTEXT)

(+,di_cfm_eax,sys_open)

(+,co_ecx,RDONLY)

2 (D,1) = (+,ALL,0,0)

# open for read-write

1 = (+,id_type,CONTEXT)

(+,di_cfm_eax,sys_open)

(+,co_ecx,RDWR)

2 (D,1) = (+,ALL,0,0)

Figure 4: Filtering rules for open system call(sys_open) with read and read-write accessflags. The (D,1) means that the rule shoulduse only the records that have matched this rulenumber in the second argument. There is also anegation counterpart (N,x) where the specifiedrecords are excluded.

put rate, so we enable event filtering. Cur-rently, this is simply collecting 1 out ofnevents wheren can be tuned. Ultimately, wewould like to be able to control the types ofevents collected to ensure that rarer events arenot missed.

The logged data identifies the objects used incontrolled operations and the authorizationsmade upon those objects. While different ob-ject instances are used in different system callinstances, objects referenced by the same vari-able (i.e., used in the same controlled opera-tions) should normally have the same autho-rizations. This is not entirely true as some sys-tem calls (e.g.,open , ioctl , etc.) may implydifferent authorizations based on the flags thatare sent. Therefore, we have defined a simplefiltering language to identify the kernel eventsthat should have the same authorizations forall objects (see Figure 4 for examples). Perfilter, all objects should have the same autho-rizations. Therefore, we can identify anoma-lous cases that do not have the expected autho-rizations, and these cases are often errors. Be-

cause the filters enable focusing on a small setof operations, we have had more success find-ing problems using the runtime analysis thanthe static analysis. We have found errors rang-ing from missing authorizations for an obscuresystem callgetgroups16 to a missing au-thorization for resetting the fowner of a file us-ing one of the flag variants offcntl (see Fig-ure 5).

The runtime analysis also does something thatthe static analysis does not: it identifies the ex-pected authorizations for an object in a systemcall. Cases that are consistent identify a be-lief in the set of authorizations that are requiredon an object. These authorization requirementscan be used as input to the static analysis toolwhich can then be used to verify the correctauthorizations, not just the existence of an au-thorization. While most of the controlled oper-ations require just one authorization, the errorin the fcntl case above was in the lack of asecond authorization to check the permissionto set the owner.

5 LSM Community Analysis Ap-proach

As might be gathered by the previous section,we find that the two analysis approaches arequite complementary. In this section, we out-line the approach intended for use by LSM ver-ification experts to verify LSM authorizationhook placement using our analysis tools. Wediscuss how the kernel development commu-nity might use the analysis tools to maintainLSM correctness in the following section.

Verification of LSM authorization hook place-ment involves the following steps:

1. Checked/Unchecked Static Analysis:We first apply our static analysis approachto find variables for which no authoriza-


/* from fs/fcntl.c */static longdo_fcntl(unsigned int fd,

unsigned int cmd,unsigned long arg,struct file * filp) {

...switch(cmd){

...case F_SETOWN:

/* set fowner is authorizedfor filp */

err = LSM->file_ops->set_fowner(filp);

...filp->f_owner.pid = arg;...

case F_SETLEASE:err = fcntl_setlease(fd, filp,

arg);...

}...

}/* from fs/locks.c */fcntl_setlease(unsigned int fd,

struct file *filp,long arg) {

struct file_lock *my_before;...if (my_before != NULL) {

error = lease_modify(my_before,arg, fd, filp);

...}lease_modify(struct file_lock

**before,int arg, int fd,struct file *filp) {

...if (arg == F_UNLCK) {

/* ERROR: could set activefowner to 0 */

filp->f_owner.pid = 0;...

}...}

Figure 5: Code path from Linux 2.4.16 con-taining an exploitable error for the system callfcntl(fd, F_SETLEASE, F_UNLCK)whereby thepid of an active lock can be set to 0.

tions are performed. Since there are asignificant number (̃30 for the VFS layeralone for2̃50 controlled variables) of typeerrors, these must be further classified toeliminate all those that are known not tobe a real error.

2. Runtime Analysis for AuthorizationRequirements: Using benchmarks thatcover as much of the kernel source as pos-sible plus potential exploits derived fortesting the remaining static analysis typeerrors, perform the runtime analysis toderive the kernel authorization require-ments.

3. Static Analysis Using the AuthorizationRequirements: More complete coverageof the kernel is possible using static anal-ysis, so repeat the static analysis using theauthorization requirements.

4. Runtime Verification Using All Ex-ploits: Repeat the runtime analysis usingany newly derived exploits from the sec-ond static analysis.

5.1 Checked/Unchecked Analysis

In the first step, the static analysis is applied tothe kernel source, and some number of type er-rors are identified by CQUAL. We have fullyautomated this process, but the problem of ex-amining type errors and determining whetherthey are exploitable must ultimately be done byan expert. The type error rate (type errors pervariable of a controlled data type) varies fromsubsystem to subsystem, but it is 12% for theVFS layer (higher than usual) in Linux 2.4.9.Therefore, we have 30 variables in the VFSlayer that are not explicitly authorized beforethey are used in a controlled operation.

Many of these type errors are not exploitableerrors, however. In the VFS layer, these type


errors come in three kinds: (1) use in initial-ization or other “safe” functions; (2) extractionof inodes from checked dentries; and (3) un-known type errors. The first two kinds of er-rors are not exploitable errors, so we need tochange our analysis to prevent them from be-ing generated. In the first case, we can rela-bel these functions, so they no longer require achecked variable. Since some functions arenot obviously “safe,” so there is some possibil-ity for error here. When these functions aremodified, some re-evaluation is necessary tomaintain is status. In the second case, we needto change CQUAL to infer achecked vari-able if it comes from achecked field, and nouser process can modify this relationship. Forexample, if we check a dentry then later extractthe inode from this dentry, the LSM hooks be-lieve that the inode is authorized also. This isbecause the dentry inode relationship is fixed(i.e., not modifiable by user processes). For sit-uations of this type, we can infer the variableis checked . CQUAL does not support thiskind of reasoning, but we are working with theCQUAL community to do this.

For other type errors, we need to find othermeans to distinguish whether they are real er-rors or not. For many of these cases, we de-velop exploit programs to try to find vulnera-bilities with respect to the LSM authorizations.At present, this is a manual process, but wewould like to automate some aspects of thisprocess based on the nature of the type error.Ultimately, some degree of manual effort willalways be required in processing type errors.

5.2 Authorization Requirements Generation

Second, we then perform the runtime analysisgiven the benchmark and exploit programs todiscover vulnerabilities, identify anomalies inauthorizations, and determine the authorizationrequirements of the controlled operations. Theexploit programs identify vulnerabilities auto-

matically, so we do not detail them further here(see the detailed static analysis paper [20] forthe program that exploits the vulnerability inFigure 3). We discuss anomaly identificationand the determination of authorization require-ments here.

The Vali runtime analysis identifies the autho-rizations that are made on each object in a ker-nel event (i.e., system call with the same ex-pected authorizations). Any variations in theauthorizations signal either a miss definitiona kernel event (i.e., the authorizations reallychange when we did not expect) or an anomalyin authorization. Recall that kernel events aredefined by filter rules. Since writing these rulesdepends on deep knowledge of the kernel andLSM authorization, we expect that the LSMverification experts will write such filter rulesto correctly generate anomalies. For example,we defined rules for open read-only and read-write cases in Figure 4.

An authorization anomaly is a case wherean authorization only occurs in some of thecases of the kernel event. In Figure 5, theset_owner authorization was missing eventhough the inode fieldf_owner was accessedin a fcntl system call. While different flagsto fcntl may result in different authoriza-tions, we found that because the same fieldswere accessed with different authorizations,there could be a potential problem. Thus, thiserror was found in trying to write an appropri-ate filter for the different variants offcntl in-vocations. A complete discussion of the differ-ent types of anomalies and their use in the clas-sification of kernel events is provided in ourruntime analysis paper [6].

Once the filters are written, they can be used bythe Vali analysis tool to generate the object au-thorizations and any anomalous authorizations.In general, an object’s authorizations may varydepending on the operations performed (i.e.,


DFN d 0 0 384 -1DFN d 0 0 384 1DFN d 0 0 400 -1...SFN(ALWAYS) d 0 0xc

Figure 6: Vali analysis output aggregating allinode and file operations with the same autho-rization. The DFN fields indicate: (1) “d” isdatatype-insensitive, meaning all operations onthe datatype have the same requirements; (2)first 0 is aggregate id; (3) second 0 is the classid for “inode”; (4) next number is the memberid accessed; (5) last is the access type code.

field and access type) and the functions inwhich the operations are performed. The Valianalysis tool aggregates the common autho-rizations first by operation type, if their autho-rizations are always the same, then by func-tion. That is, we hope that all operations in anevent have the same authorizations. If not, thenother operation attributes are used to aggregatewhen the authorizations are the same for op-erations with the same attribute value. We useoperation datatype, object, member access, andaccess+function as the aggregation attributes.Figure 6 shows a datatype aggregation for in-odes in theread system call (files are also ag-gregated). Figure 7 shows that authorizationsmay vary depending on the member access orthe function in which the access is performed .The aggregation attributes are totally-ordered,so we try to aggregate at the attribute that yieldsthe largest aggregate.

Maximizing aggregation also has the positiveoutcome that it reduces the number of regres-sion differences. For example, if a controlledoperation has the same authorization require-ments regardless of the function in which it isrun, then moving or adding the operation to anew function does not signal a regression dif-ference.

DFN f 0 0 320 -1SFN(ALWAYS) f 0 0x37

DFN f 1 0 1152 1SFN(ALWAYS) f 1 0x13

DFN i 0 0 1216 1 ext2_lookup...SFN(ALWAYS) i 0 0x1a

DFN i 1 0 1216 -1 find_inodeSFN(ALWAYS) i 1 0x37

Figure 7: Vali analysis output showingfour groups offunction-insensitive(“f”) andfunction-internals-sensitive(“i”) operationsfor stat64. Function-insensitive accesses havethe same authorizations regardless of the func-tion in which the dangerous operation appears.Function-internals-insensitive operations havedifferent authorizations as accesses to member1216 in the two functionsext2_lookup andfind_inode identify.

When all anomalies have been resolved, thenthe output defines the authorization require-ments for the controlled operations in the ker-nel events in which they are run. Of course,some authorizations could be missing entirelyfor all runs, but we expect that the aggregatedrequirements will make it possible to verifythis with reasonable effort.

5.3 Static Analysis Using Requirements

The authorization requirements found usingthe Vali runtime analysis can be used as inputto the CQUAL static analysis. Three changesmust be made to use the authorization require-ments:

1. Authorizations must result in variables ofa qualified type of the authorization made.

2. Functions annotations must be changed to


expect parameters of qualified types de-pending on the authorizations expected.

3. A type qualifier lattice must be built thatrepresents the legal relationships betweentype qualifiers.

In the first case, we must now changeunchecked variables to a qualified typecommensurate with the authorization (e.g.,read_authorized ). Given that a variablecan have multiple authorizations that dependson the kernel’s control flow, such annotation it-self is a subject of static analysis. CQUAL doesnot help with annotation (i.e., it is an input toCQUAL), so we must devise another techniquefor proper annotation. Fortunately, objects al-most always have only one check, and no morethan three, so this problem is handled manuallyat present.

The Vali authorization requirements for con-trolled operations generated from the Vali run-time analysis are used to identify the type qual-ifier requirements of functions. Figure 8 dis-plays the output data from Vali used as inputto this process. Variables are identified by theirline number, data type, member access, and ac-cess type. While this is not completely unam-biguous, it is sufficient for the kernel currentlyand we can identify ambiguities that cannot beresolved automatically. The SFNs identifiedas ALWAYS indicate the authorization require-ments to be enforced on this variable.

Since multiple kernel events may use the samefunctions, the type qualifiers are, in general,the OR of these cases. This is represented us-ing CQUAL’s type qualifier lattice [8]. SinceCQUAL’s granularity is a function, code withina function that is called only when different au-thorization requirements are expected will notnecessarily be handled properly by CQUAL.An example of this islease_modify in Fig-ure 5 where the authorization forset_owner

DFN(namei.c, 207)(OT_INODE, 1152, -1)SFN(ALWAYS): SCN_INODE_PERMISSION_EXECSFN(ALWAYS): SCN_INODE_PERMISSION_WRITESFN(ALWAYS): SCN_INODE_UNLINK_DIRSFN(NEVER): SCN_INODE_UNLINK_FILESFN(NEVER): SCN_INODE_DELETE

Figure 8: Vali runtime output for the authoriza-tion requirements for a controlled operation inthe unlink system call. The DFN indicatesthe line number, variable type, operation, andaccess which can be used to identify the vari-able in most cases. The ALWAYS SFNs indi-cate the authorization requirements.

is only necessary if(arg == F_UNLCK) .Where a combination of authorizations to afunction are of the formA ∨ (A ∧ B) whereA andB are authorization types, then we mayneed to manually annotate the code whereA ∧B is required. We can do this by creating adummy function call that requiresA ∧ B. Ul-timately, better intra-procedural analysis is re-quired to find blocks of code within functionsthat require different authorizations, however,because such manual annotation limits regres-sion testing (see Section 6.1).

5.4 Further Exploit Verification

Any exploit programs derived from the secondstatic analysis are added to the Vali runtimeanalysis benchmarks, and runtime analysis isrerun. Since these programs are mainly look-ing for vulnerabilities, rather than anomalies,the output will be largely unchanged from step2.

6 Kernel Community Approach

As the kernel evolves, the placement of theLSM authorization hooks may be invalidated.Since the kernel development community atlarge will modify the kernel, we need an ap-


proach in which the kernel modifications canproceed while maintaining the verification sta-tus of the LSM authorization hooks. Clearly,the kernel development community will not beinclined to perform the verification process ofthe LSM community as described above. How-ever, it is possible for the kernel developmentcommunity to leverage this work to maintainLSM verification.

Basically, we envision that kernel developer’stask in maintaining the LSM authorizationhook verification will involve regression test-ing on the static and runtime analyses. As partof an extended kernel build, the static analysisprocess can be run as in step 3 of the LSM com-munity process above. The type errors gen-erated above can be compared to the existingclassifications to verify that no new type errorsor type error paths are created.

Since some unresolved type errors are likely toremain for a while, it is ultimately necessary toperform runtime regression testing. While thistask requires more work because the new ker-nel must be run, much, if not all, of this taskcan also be automated. In this case, the goal ofthe kernel development community is to iden-tify any new anomalies or new authorizationrequirements (e.g., if a new object is added)to the LSM community. As described below,the Vali runtime analysis tool can identify suchdifferences automatically.

6.1 Static Regression Testing

Since the GCC annotation process, CQUALanalysis, and output classification can be per-formed automatically, static LSM regressiontesting can be integrated as an extension to theautomated build process. We first describe thetasks that are necessary to automate static anal-ysis as part of the build process. While theanalysis will generate the output automatically,some situations arise in manual analysis is cur-

rently required. We list these cases and exam-ine their implications.

The build process for static analysis consists ofthe following steps:

• GCC analysis: Our extended GCC com-piler must be used to build the kernel. Thecompiler creates a log of controlled op-erations, controlled variable declarations,and LSM authorization hooks. The fol-lowing Makefile modifications are neces-sary:

CC = $(CROSS_COMPILE)/\$(VALI_GCC)/gcc \

--param ae-analyses=8243

The parameterae-analyses indicatesthe types of information that our extendedGCC compiler gathers.

• Perl annotation: Perl scripts have beenwritten to pre-process the GCC analysisoutput into a form that is then used bya second set of Perl scripts to automati-cally annotate the Linux source code withCQUAL type qualifiers.

The GCC analysis generates output foreach controlled operation, such as seen inFigure 9.

The first set of Perl scripts processes suchoutput into the form:

/usr/src/linux-2.4.9-\.../fs/attr.c:61 \inode_setattr *inode

• CQUAL Linux build : CQUAL requiressome pre-processing of the Linux sourcecode before it can perform the analysis(e.g., removal of blanks and comments).The standard GCC compiler can be usedfor this step.


DEBUG_ACCESS: controlled operation:file = /usr/src/linux-2.4.9.../fs/attr.ccurrent_function = inode_setattr.function_line = 63.current_line_number = 66access_type = writename = (*inode)member = i_uid (384)is_parameter = 1.

DEBUG_ACCESS: controlled operation:file = /usr/src/linux-2.4.9.../fs/attr.ccurrent_function = inode_setattr.function_line = 63.current_line_number = 68access_type = writename = (*inode)member = i_gid (416)is_parameter = 1.

Figure 9: The GCC analysis output.

$(CC) $(CFLAGS) -E $< | \$(CQUALBINDIR)/remblanks >$*.ii

• CQUAL analysis: CQUAL can then beused to perform the static analysis. Thefirst step runs the CQUAL analysis. Thesecond step generates the type error pathinformation. See Figure 10.

• Authorization requirement annotation :Vali runtime analysis generates authoriza-tion requirements per controlled operationas shown in Figure 8. We are in the pro-cess of writing Perl scripts to apply theserequirements to the annotation of autho-rizations specific to the requirements de-scribed above. We hope to be able to re-port on this at the symposium.

While we have not done detailed time measure-ments, we have found that the entire analysisadds about 10 minutes to the build time. GCCanalysis adds little overhead to the kernel build.Perl processing takes about 5 minutes for the

kernel. CQUAL analysis takes approximatelyanother 5 minutes for the kernel.

The current static analysis process verifies thatthe LSM authorization hook placement is cor-rect, but some situations need further, manualexamination. These cases are listed below:

1. Changes to “safe” functions: The GCCanalysis identifies the addition of a newcontrolled operation to a function for-merly classified as “safe,” see Section 5.1.

2. Changes to manually annotated func-tions: A source comparison detects achange to a function with any manualannotation (e.g., the addition of dummyfunctions for ORed authorization require-ments, see Section 5.3).

3. New type error variables: The CQUALanalysis identifies any new variables thathave type errors.

4. New shortest type error paths: The


$(CQUALBINDIR)/cqual -prelude \$(CQUALDIR)/config/prelude.i.security -config

$(CQUALDIR)/config/lattice.security attr.ii 2>attr.path

Figure 10: Performing static analysis with CQUAL.

CQUAL analysis identifies any new short-est type error path for a variable with anexisting type error.

The first two situations are cases where thedependencies of the analysis have changed,such that the analysis may no longer be sound.While we hope to eliminate such dependenciesthrough further analysis, we expect the analy-sis will always be subject to some number ofdependencies. In fact, as the analysis becomesmore elaborate, the complexity of dependen-cies increases, so the current set may prove tobe the best option.

The second two situations are the identificationof a new type error that may indicate a realvulnerability. In order to reduce the numberof false positives, secondary analyses are nec-essary to identify them. These analyses mayhave dependencies (e.g., that is the cause ofcase 1), so the cost of managing the dependen-cies must be less than the value of removingthe false positives.

While it is not completely clear where the bal-ance between manual effort on the part of thekernel developer and LSM community is in thisprocess, we anticipate the following. Our goalis that most notifications of case 1 and 2 canbe handled trivially by the kernel developmentcommunity and the LSM community can ver-ify. Errors of case 3 and 4 may also be han-dled by the development community in manycases, but again the LSM community may dodeeper verifications and develop classifiers toeliminate identifiable false positives.

6.2 Runtime Regression Testing

Since we expect that there will always be somenumber of type errors for which exploits canbecome possible and some tasks that are moreeasily or better done by runtime analysis, westrongly recommend performing the runtimeregression analysis. However, this analysis ismore time-consuming than the static analysisin two key ways: (1) the instrumented ker-nel must be built and (2) the runtime analy-sis benchmarks must be executed on the instru-mented kernel.

At present, the build process for a Vali-instrumented kernel, runtime logging modules,and analysis tools is completed automated.However, the execution of the analysis is notautomated at present. The main tasks that arenot automated are: (1) the collection of in-struction pointer locations for kernel entry/exitpoints used to identify the kernel events and (2)the runtime execution. The first task only in-volves “grepping” the generated object dumpfor a few well-known instruction, so it appearsstraightfoward to automate this. We are look-ing into how to automate the runtime data col-lection using VMware4.

In order to enable regression testing, the Valiruntime analysis tool generates output thatdoes not include line number or instructionpointer information, so that regression can bedone across minor kernel modifications. Fur-ther, aggregation of controlled operations thatare not function-sensitive enables regressionacross kernel modifications regardless of func-

4VMware is a trademark of VMware, Inc.


tions executed in a kernel event.

Figures 6 and 7 give an idea of how the outputfrom the Vali runtime tool enables regression.The output shows the controlled operationswith the same authorization requirements. Incases where the authorization requirements ofcontrolled operations are sensitive to the func-tion in which the operation is run, more in-formation is displayed. In this case, if thecontrolled operation is moved from one func-tion to another, the regression test identifies thechange.

Given aggregation, the following types ofchanges between regression tests are possible:

• New controlled operation in an aggre-gate: An operation has been added, and ithas been classified with an existing aggre-gate.

• Remove controlled operation from anaggregate: An operation has beendeleted, so it no longer appears.

• Move controlled operation to anotheraggregate: Either an authorization or anoperation has been moved such that adifferent set of authorizations are activewhen the operation is performed.

• Create a new aggregate: A new set ofauthorizations has been created or a newsensitivity has been triggered such that anew aggregate of operations and permis-sions has been created.

The addition and removal of controlled opera-tions is not a major change if they adhere to theexisting aggregates. However, it is always wiseto verify that the operations are consistent withthe aggregations assigned to them. The moveof operations to other aggregates or the cre-ation of new aggregates are significant changesthat warrant review.

7 Conclusions and Future Work

In this paper, we outline static and runtimeanalysis tools that we have developed to ver-ify the correctness of LSM authorization hookplacement. These tools have been used to findfive, since fixed, errors in LSM hook place-ments. We believe that such verification shouldnot be a one-time process, but rather it shouldpractical for kernel developers to perform re-gression testing as the kernel is modified. Theproblem is to automate the analysis processas much as possible and only provide test re-sults that really require examination by the de-velopment community, as much as possible.We demonstrate that static analysis process andmost of the runtime analysis process are au-tomated already. We also identify the typesof analysis results that the tools will report tothe developers. While it is nice to eliminate asmany false positives as possible, we are limitedby the Halting Problem as to how many can beremoved in general and the means for identi-fying false positives introduces dependenciesthat also must be verified. At present, wedo not eliminate most false positives automati-cally, but expect that the LSM community willidentify them as such and regression over thesewill be sufficient (i.e., as long as few, new falsepositives are introduced little effort will be re-quired to handle them). The generated outputis low-level which enables quick comparison,but still makes is difficult for developers. Inter-faces for handling this information are a signif-icant area of future work.

References

[1] A. Berman, V. Bourassa, and E. Selberg.TRON: Process-specific file protectionfor the UNIX operating system. InProceedings of the 1995 USENIX WinterTechnical Conference, pages 165–175,1995.


[2] M. Bishop and M. Dilger. Checking forrace conditions in file accesses.Computing Systems, 9(2):131–152, 1996.

[3] N. S. Borenstein. Computational mail asa network infrastructure forcomputer-supported cooperative work.In Proceedings of the Fourth ACMCSCW Conference, pages 67–74, 1992.

[4] Wirex Corp. Immunix securitytechnology. Available athttp://www.immunix.com/Immunix

/index.html .

[5] A Edwards. [PATCH] add lock hook toprevent race, January 2002. LinuxSecurity Modules mailing list athttp://mail.wirex.com

/pipermail

/linux-security-module

/2002-January/002570.html .

[6] A. Edwards, T. Jaeger, and X. Zhang.Verifying authorization hook placementfor the Linux Security Modulesframework. Technical Report 22254,IBM, December 2001.

[7] D. Engler, B. Chelf, A. Chou, andS. Hallem. Checking system rules usingsystem-specific, programmer-writtencompiler extensions. InProceedings ofthe Fourth Symposium on OperationSystem Design and Implementation(OSDI), October 2000.

[8] J. Foster, M. Fahndrich, and A. Aiken. Atheory of type qualifiers. InACMSIGPLAN Conference on ProgrammingLanguage Design and Implementation(PLDI ’99), pages 192–203, May 1999.

[9] I. Goldberg, D. Wagner, R. Thomas, andE. Brewer. A secure environment foruntrusted helper applications. InTheSixth USENIX Security SymposiumProceedings, pages 1–12, 1996.

[10] T. Jaeger and A. Prakash. Support for thefile system security requirements ofcomputational e-mail systems. InProceedings of the 2nd ACM Conferenceon Computer and CommunicationsSecurity, pages 1–9, 1994.

[11] D. Larochelle and D. Evans. Staticallydetecting likely buffer overflowvulnerabilities. InProceedings of the10th USENIX Security Symposium,pages 177–190, 2001.

[12] S. Minear. Providing policy control overobject operations in a Mach-basedsystem. InProceedings of the FifthUSENIX Security Symposium, 1995.

[13] NSA. Security-Enhanced Linux(SELinux). Available athttp://www.nsa.gov/selinux .

[14] LIDS organization. Linux intrusiondetection system. Available athttp://www.lids.org .

[15] A. Ott. Rule set-based access control(RSBAC) for Linux. Available athttp://www.rsbac.org .

[16] U. Shankar, K. Talwar, J. S. Foster, andD. Wagner. Detecting format stringvulnerabilities with type qualifiers. InProceedings of the 10th USENIXSecurity Symposium, pages 201–216,2001.

[17] R. Spencer, S. Smalley, P. Loscocco,M. Hibler, and J. Lepreau. The Flasksecurity architecture: System support fordiverse policies. InProceedings of theEighth USENIX Security Symposium,August 1999.

[18] Argus Systems. Argus PitBull LX.Available athttp://www.argus-systems.com .


[19] L. Torvalds and C. Cowan. Greetings,April 2001. Linux Security Modulesmailing list atmail.wirex.com/pipermail

/linux-security-module

/2001-April/000005.html .

[20] X. Zhang, A. Edwards, and T. Jaeger.Using CQUAL for static analysis ofauthorization hook placement. InProceedings of the 11th USENIXSecurity Symposium, 2002. To appear.

Proceedings of theOttawa Linux Symposium

June 26th–29th, 2002Ottawa, Ontario

Canada

Conference Organizers

Andrew J. Hutton,Steamballoon, Inc.Stephanie Donovan,Linux SymposiumC. Craig Ross,Linux Symposium

Proceedings Formatting Team

John W. Lockhart,Wild Open Source, Inc.

Authors retain copyright to all submitted papers, but have granted unlimited redistribution rightsto all as a condition of submission.

maintaining the correctness of the linux security modules ... · maintaining the correctness of the...

Documents