Re: Extending a Security Module

From: Chris Wright (chrisat_private)
Date: Tue May 22 2001 - 14:41:55 PDT

  • Next message: jmjonesat_private: "Re: Extending a Security Module"

    * jmjonesat_private (jmjonesat_private) wrote:
    > On Tue, 22 May 2001, Chris Wright wrote:
    > > 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.
    load both modules.
    modprobe my_module
    modprobe capability_plug /* security_ops->register() will get called */
    start a new task
    create a security blob for the new task
    	task->security = kmalloc(sizeof(my_big_security_blob, GFP_KERNEL);
    	/* this will overwrite the opaque security blob, so you'd
    	 * better save off your stuff.  how do you combine them back
    	 * in general? 
    maybe you only care about the registered ops for the capable() call.
    	/* this implicitly expects current->security to be a 
    	 * capabilities specific opaque blob, 
    My point is you have to accomadate two modules needs in one opaque blob.
    So the registrar module must know the details of the opaque blobs of the
    registered module.
    linux-security-module mailing list

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