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

Download Maintaining the Correctness of the Linux Security Modules ... ?· Maintaining the Correctness of the…

Post on 27-Jul-2018




0 download

Embed Size (px)


  • 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}


    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 systems 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 kernels 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-

    erated 1. 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 positive 2,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.

  • Ottawa Linux Symposium 2002 225

    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 user root, 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 usersprocesses should always have all of the usersrights 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 th