Re: [RFC][PATCH] Extended Attributes for Security Modules

From: Stephen Smalley (sdsat_private)
Date: Wed Apr 16 2003 - 06:47:22 PDT

  • Next message: richard offer: "Re: [RFC][PATCH] Extended Attributes for Security Modules"

    On Tue, 2003-04-15 at 12:58, richard offer wrote:
    > I see modules as empheral, but attritbutes as permanant. If I'm running one
    > LSM module, I reboot and use a different LSM module, what happens to the
    > attributes that the first module added to the file ?
    > 
    > Either we should guarantee that modules only touch attributes they know
    > about---ignoring all others (but not overwriting them), or we have separate
    > namespaces for each module's attributes.
    > 
    > Stacking modules will work with either scheme, but its seems to be that
    > switching policies over a reboot could easily be broken by a scheme that
    > shared a single namespace.
    
    Thanks for your comments.  It occurred to me after I sent my initial
    reply that you might be thinking of a scenario where you have two
    different security modules for two different environments, and you
    switch back and forth between them depending on what environment you are
    working in.  However, I think that this scenario is fundamentally
    flawed, as the two modules will end up needing to be tightly coupled in
    order to provide any continuous guarantees of security and would be
    better implemented as a single module that understands two (or n) states
    of operation and has a mechanism for secure transitions between those
    states.  If you keep them as independent modules, then each module has
    no way of knowing what kind of data mixing occurred while the other
    module was active, so the old attributes of existing files are no longer
    trustworthy, and each module has no way of knowing how to handle new
    files that were created while the other module was active.  You really
    need the two modules to be aware of each other and to maintain
    sufficient state information so that the other module can recover to a
    secure initial state, at which point you might as well merge them into
    one module with multiple states of operation.  A single module with
    multiple states of operation can also potentially support transitions on
    events without a reboot (or the overhead of a full module
    removal+insertion), so you have greater flexibility.
    
    -- 
    Stephen Smalley <sdsat_private>
    National Security Agency
    
    _______________________________________________
    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 : Wed Apr 16 2003 - 06:48:50 PDT