USENIX Security LSM BOF Notes

From: Crispin Cowan (crispinat_private)
Date: Wed Aug 15 2001 - 18:14:15 PDT

  • Next message: Theodore Tso: "Re: Making forward progress"

    Chris Wright:  presented an overview of the LSM project.  None of it
    should be news to regular readers of this list.
    A New Security Architecture for Hosting Internet Services
    What is HP-LX?
       * a highly secure version of Linux for running applications and
       * building on the success of HP VirtualVault
            o balance ease of use with security
            o a new security model focused on internet services and
       * minimal kernel changes
       * HP will deliver
            o sample applications, e.g. apache
            o ...
    HP-LX In Context
       * graph that looks a lot like ours
    Review of Major Features
       * containment
       * file system protection
       * system configuration lockdown
       * audit
       * secure administration
       * future features
       * major feature of the product
    example of compartment communciation rules
       * host:*-> compartment rules ...
       * stripped down version from VirtualVault
    Secure administration
       * based on SSH
    Future Features
       * patch checking and system scanning
       * application integration tool
       * more sophisticated compartment management tools
            o currently just have command line utilities
       * management
            o integration with popular managment platforms:  OpenView, etc.
       * Secure networking
            o distributed containment
       * fial-over support
       * intrusion detection
       * more applications
    Stephen Smalley, NAI
    What is SELinux
       * Implementation of flex., fine-grained nondiscretionary access
         controls for linux
       * clean sep. ..
    Why would you want to use it?
       * to confine malicious mobile code that exploits a flaw in your web
       * to confine an exploit of a flaw in apache, bind, sendmai, or any
         other system service
       * to prevent unauth. mods of your system software, config files, and
       * to protect e confidentiality or integrity of sensitive info
       * to safely run a program of uncertain pedigree
       * ...
    SELinux and LSM
       * SELinux orig. impl as a kernel patch
       * presented at 2.5 kernel summit
       * linus provided feedback on what he is willing to accept into the
         kernel: a comon set of kernel hooks that can support many diff.
         security projects
       * LSM is a communit effort coord. by WireX to devle a kernel patch
         that provides such hooks
       * ...
       * SELINUX:
       * LSM
    Testing and Verification for LSM
    Trent Jaeger and Antony Edwards IBM Research, T.J. Watson Lab
    Placement, Verification, Management of Kooks is Key
       * Hooks in front of dangerous operations within the kernel
       * hooks call out to the LSM module(s)
       * risk:  hooks may not be close enough to dangerous operations to
         effectively prevent damage
    Tools We Are Working ON
       * Initial concern: correctness and ease of hook management
            o cna reasonabele management toolset be created
       * top-down:  hook, location -> identify protected op
            o static, sanity check, documentation, limited static regression
       * Bottom-up: dangerous op, location -> runtime security context
            o runtime, correctness, regression
    Top-down Hook Analysis
       * for each hook in LSM kernel:  find location, logical operation,
         protected operation
       * location, logical operation are in hook
       * how easy is it to deduce the protected operation?
       * generally easy except for implicit, misordered variables,
         intermediate variables, and optimized cases
       * express consistently but remove overhead via tools
    Bottom-Up Analysis
       * for each dangerous operation
            o determine the security contexst for the operation
            o compare to the expected security context
       * how do we identify dangerous ops?
            o security updates, function ptrs for modules
            o instruction location, symbol of interest
       * what determines a correct authorization?
       * ...
    Linux LSM at SGI
    Richard Offer, SGI
    goals: evaluatable configurations
       * CAPP:  Existing Linux Access Control + Audit
       * LSPP:  Mandatory Access Control + Audit
       * Native implmentation of POSIX MAC and audit
    Pre-LSM Audit
       * CAPP
            o functionally complete since fall 2000 [2.2]
            o ported to 2.4.5 bewfore LSM started
            o code comprised
                 + kernel "hooks" created, filled and finalized records
                 + audit library [POSIX API]:  95% shared source
                      + kernel component
                      + user-land component
                 + audit aware applications, e.g. LILO
    CAPP Audit as an LSM Policy
       * Redesign under LSM as a work in progress
            o LSM hooks
                 + only fill in record
            o new syscall handler creates & finalizes records
                 + requires learning assembler for all [supported]
                   platforms, but small enough to bear ongoing maintenance
       * LSM makes it easier to distribute new policies
       * Restrictive vs Authoritative Hooks
            o Position of hooks
                 + wagner/jones proposal seems workable to everyone's equal
                   dissatisfaction.  But no progress made
       * Kernel logic moved to module
            o no solution, linux 3.0?
       * module interfaces
            o /pro, system call?
    Applications have policies too
       * ld: get and show process attributes
       * ls: get and show file attributes
       * sendmail: is recipient cleared for e-mail?
       * X: can cut-n-paste between windows [classic CMW]
    Hot Issues
       * name vs. inode (hopefully moot
       * ordering of in-kernel and in-module check
            o restrictive vs. authoritative
       * push in-kernel out (not looking favarable
            o CONFIG_LSM
       * runtime identificaton of module
       * syscall interface
       * feedback on cool new netowrk hooks
       * what to do w/ capabilities module?
       * UNIX domain sockets using abstract namespace
       * submit patch?
    name vs. inode
       * need some way to recover the absolute path name of the file
         requested by the application
       * problematic in 2.4
       * good news:  in 2.5 the permission() call will provide both the vfs
         mount point and the dentry, which will allow modules that need it
         to get either the pathname or the inode
       * Q: why are there not read and write hooks?
       * A: because read and write call permission, so one hook in
         permission satisfies.
    Ordering of in-kernel vs. module check
       * problem:  some projects want DAC (in-kernel) checks done first,
         while others want MAC (module) checks done first
       * conjectured solution:
            o do DAC checks first
            o convert all the hooks to be "authoritative", where the DAC
              result is given to the module, which makes the final
            o place additional hooks so that "short circuit" cases where the
              kernel does a DAC-deny early pass that result to the module
       * Problem with the conjectured solution:  the "short circuit" hooks
         are numerous, and potentially complex.
            o Crispin: can we supply semantically simpler hooks for the
              short-circuit cases, so the kenrel is only sending the DAC
              return code to the module for post-processing?  Problematic.
            o Stephen: how about using the capable() hook to always return 1
              ofr CAP_DAC, which effectively turns off ALL in-kernel DAC
              logic, and punts the problem to the module.  This makes it
              possible for SGI to do what they want, at the cost of
              re-implementing DAC logic in the module.
       * Action:  SGI should look at Stephen's early June authoritative
         patch, and determine to what extent it will satisfy their needs.
         To the extent that it falls short, SGI should identify what is
         needed in addition.  It is important that the cases SGI looks at
         not be just the simple ones; there are hard cases that need to be
    Push in-kernel logic out to a module:  no
    Make it possible to config away LSM
       * Linus:  no conditional compilation
       * Ted: urges us to make LSM config-awayable.  It's oky to put
         #ifdef's in header files
       * We can do it either way, but would rather not do it both ways just
         to guess which is right.
       * Action:  reply to Ted that the current impl. is not consistent with
         his configable suggestion, and ask him to clarify.
    Runtime Module Identification
       * We want to have a syscall interface for applications to explicitly
         interact with modules.
       * Some applications want to know whether there is a particular module
       * Some systems (SELinux) pass a module identifier as one of the
       * Stephen wants a convention that one argument is a magic number used
         to identify the module.  So long as this is strictly a convention,
         and has no impact on the LSM code per se, there is nothing to
         object to.  There are two code requirements:
            o Change the syscall interface from (int, vector) to be (int ,
              int , vector).  Stephen will (by convention) use the extra int
              as a module identifier, but the LSM interface won't know that,
              it will just pass it through.
            o Ensure that the LSM dummy module returns ENOSYS appropriately
              when the syscall is called.
    Without making it to the end of the Hot Topics list, we ran out of time
    & patience, and ajourned.  But at least we resolved several important
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc.
    Security Hardened Linux Distribution:
    Available for purchase:
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 18:16:45 PDT