Re: Extending a Security Module

From: jmjonesat_private
Date: Tue May 22 2001 - 14:15:22 PDT

  • Next message: Chris Wright: "Re: Append vs. write distinctions"

    On Tue, 22 May 2001, Chris Wright wrote:
    > * jmjonesat_private (jmjonesat_private) wrote:
    > > 
    > > Unless I'm missing something,
    > > 
    > > create security_ops->register()
    > > create security_ops->unregister()
    > > 
    > > If register_security() detects an existing module registration,
    > > instead of failure, pass the new ops pointer to the 
    > > security_ops->register() function.
    > > 
    > > If the module can't provide "chaining" or replacement functions,
    > > it could just fail, if it CAN, it returns success and can worry 
    > > itself if it calls the new hook before or after or never,
    > > and possibly unregister and register a new structure since it 
    > > holds "the magic address".
    > This would work for your needs (the lsmexample plus capability_plug).  I'm
    > not sure it would solve the general problem.  First issue...what is the
    > composite meaning of a hook.  
    Kernel calls it's registered function, module has a function there that
    may or may not call the "subordinate" registered function, if it decides
    that access is allowed.  Pass down the chain.
    Any module that will not call the "subsequently registered" function,
    probably should return FAILURE on a registration attempt, although it 
    might be useful for it to return SUCCESS and just *not*.  Policy issue.
    > Your proprosal does turn this in to a policy
    > decision for each module writer (do you let later modules override your
    > decisions or not).  Do you trust a random module registering with you?
    Define "random", last I knew only ROOT could install a module.
    But, less flippantly, the concept of module identification is not
    addressed by my proposal, right.  I, for one (all alone) think this 
    is a policy issue and should be moved to the module.  If the certifying
    module wishes to "identify", an item can be added somewhere by the 
    "approved" modules to so do.
    If you do not wish to "trust", and you're high on the list, you can return
    failure for any subsequent registration attempt.  If you're LOW on the list, 
    you may not have that right anymore, thereby moving that decision to the 
    first loaded, higher priority module... and the admin who configured
    the system (fear us, we actually USE these things!!)(G)
    > Second, what do you do when you _both_ want to access the security blob?
    > Copying things in and out of the security blob isn't too nice, nor is ugly
    > casting with special purpose structs.  I don't think we can go this route.
    Perhaps I was unclear.  The second security_ops structure is in NO WAY
    the problem of the kernel proper.  The hooks call the first registered,
    always, but if a module wants to provide extensions, it just saves the
    vector and IN ITS FUNCTIONS (the one's registered) invokes those at will.
    The MODULE allows extension calls, or not.  If a field in the structure is
    passed that is NULL, the module doesn't replace it's own code... in fact,
    it NEVER *must* replace its own code, just do a "call" to the newly
    registered function when it is appropriate.  Think of it as a "second
    set of hooks" in the module, rather than anything in the kernel proper. It
    could also fail if a "nonreplacable" pointer was replaced.  This is
    TOTALLY up to the module in place, since failures of the FIRST
    register_security() would pass the structure down the chain.
    The subsequently registered "security_ops" structure is kept in the
    module, not the kernel, so it must be invoked from there... UNLESS the 
    module decides (by whatever policy) that it's "unworthy" and the new
    module should be "first", then it can unregister the "valid" structure,
    and replace the new one, and subsequently call "register_security()" in
    hopes of getting higher on the list.
    > -chris
    Perhaps I don't Understand Your Argument,
    J. Melvin Jones
    Kernel Proper: The Core Kernel without modules.
    > _______________________________________________
    > linux-security-module mailing list
    > linux-security-moduleat_private
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue May 22 2001 - 14:16:49 PDT