RE: Kernel Security Extensions USENIX BOF Summary

From: KRAMER,STEVEN (HP-USA,ex1) (steven_kramerat_private)
Date: Thu Jul 05 2001 - 09:58:01 PDT

  • Next message: Stephen Smalley: "Re: Kernel Security Extensions USENIX BOF Summary"

    Let me paraphrase the concerns I brought up at the LSM BoF last week.  The
    main LSM thrust is to beat a deadline for 2.5.X kernels and get LSM approved
    and integrated into those kernels.  Everyone is working diligently towards
    that goal.
    In my 20 years of experience porting security to mainstream UNIX-type
    systems, the initial port is only half of the battle.  In the first port,
    one is concerned
    about the security architecture, optimum placement of the hooks, and other
    aspects
    of smooth integration.  The more challenging political problems come later.
    Either the security team gets the main developers to adopt the security
    hooks in
    the mainstream code, or the porting continues anew, on the next rev of the
    mainstream kernel.  
    
    Unfortunely, most of the cases I've seen are the latter,
    where the mainstream kernel developers ignore security, and leave it to the
    security group to repeatedly re-integrate the same security hooks into the
    kernel.
    The only "challenging" work is when mainstream code changes.  This can be as
    small
    a change as an optimized version of a local routine, or as pervasive as
    changing
    from BSD sockets to STREAMS.  
    
    The couple of times I've seen attempts to integrate security into the
    mainstream
    kernel after the initial port, I've not seen it succeed.  The average kernel
    developer does not understand security, and it shows in the resulting
    kernel.
    Even those who try to "get it right" can fail in subtle, yet disasterous,
    ways.
    I've seen that on the larger rewrites, the security code is just missing.
    The
    same is true when new functionality is put in.  With it typical that
    everyone is
    under deadline, the sad choice for the security team is to 1) have the
    security
    hooks taken out of the mainstream kernel altogether, forcing the typical
    security
    port after-the-fact, 2) leave them in the kernel with an ifdef that is never
    turned on in the production kernel (and forcing the same
    after-the-fact-port), or
    3) holding up the release.  This last option is political dynamite, because
    the
    security team is seen as holding the release.  (It appears the last in line
    in a
    release is typically the accused.)
    
    Because I didn't read any of this type of discussion on the LSM list, I
    brought it
    up at the BoF.  Someone asked me what could we do to prevent this from
    occuring
    to LSM.  My response, after some discussion, was the best we could do was a
    three-pronged strategy.  First, develop a LSM test module. (More on that
    below.)
    Second, diligence by the LSM group in making sure, as early as possible in
    development, that the LSM hooks are preserved and also integrated properly
    into
    new code.  Third, this being open source development, some of the political
    pressures found in closed software shops may not be as readily
    counterproductive
    to maintaining LSM hooks by the kernel developers.
    
    
    The LSM test module I proposed has a dual purpose: 1) to ensure all the LSM
    hooks
    exist in the kernel, and 2) that they are called in the appropriate places.
    The
    LSM test module would need a small application to exercise it.  The LSM test
    module is not intended to implement yet-another-security-module, but instead
    to
    aid in the integrity of the hooks.  My intention was that it be used by
    developers of security modules, but also kernel developers.  At the present
    time,
    kernel developers have a reason for dropping or misplacing security hooks --
    there is no tool or document that explains the purpose of the hook or helps
    check
    to see if it is invoked properly.  (Remember, some developers may throw up
    any
    flag they can to see LSM fail.  Others will just make mistakes in forgetting
    about
    security.)  Because of some reluctance in getting LSM
    approved by the powers-that-be, I would think a test tool would mitigate
    some of
    those types of arguments.  (A LSM functional spec would also help, but I'm
    not
    going there [yet].)
    
    Another reason for the test tool is to make test tools for the various
    security
    projects easier themselves.  That a LSM test tool validates security hooks
    in
    the kernel is one less test scaffold required to be written by the
    individual 
    security implementations.
    
    The LSMExample module that jmjones is a start in implementing the type of
    test
    module I am describing.  With an appropriate "driver app", it provides
    coverage
    of all the LSM hooks.  Clearly, that would be useful as a first step in
    future
    kernel development.  What it lacks is a validation of the manner in which
    those
    hooks are called.  The a driver app for the LSMExample, as written, would
    not 
    distinguish if the LSM hooks were distributed throughout the kernel as they
    are now, or if they were all bunched up in main().  The LSMExample module
    needs
    to have the ability to return multiple values (minimally 0,1 on straight
    conditional hooks - maybe more on those returning other values) on those
    routines
    that can do so.  It's not enough for a LSM hook in a conditional to be
    merely 
    counted.  In other words, the mere presence of the LSM hook does not
    guarantee
    that is is invoked properly within the kernel.
    The test tool needs to have the app/module validate rudimentary control
    flow.  For 
    example, one wants to validate that this hook (from kernel/sys.c) is placed 
    correctly:
    
      no_nice = security_ops->task_ops->setnice(p, niceval);
                    if (no_nice) {
                            error = no_nice;
                            continue;
                    }
    
    A simple counter would not detect the erroneous hook:
    
      (void) security_ops->task_ops->setnice(p, niceval);
    
    The app would need to invoke nice(2) minimally twice, resulting in no_nice 
    being 0 and non-zero so that the "if" code is tested.  The app would of
    course
    need to detect that the result from nice(2) corresponded with the expected
    value.
    (Similar discussion for detecting the hook in an incorrect place.)
    
    Steve Kramer
    
    
    
    
    > -----Original Message-----
    > From: jmjonesat_private [mailto:jmjonesat_private]
    > Unless I misunderstand, LSMEXAMPLE already pretty much covers 
    > this need...
    > every hook is intercepted and a count is maintained of how many times 
    > each is called.  A simple revision can reduce that to a 
    > vector as another
    > result available to user-land.  
    > 
    > 
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Thu Jul 05 2001 - 09:59:55 PDT