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 DEFINITION: Kernel Proper: The Core Kernel without modules. > _______________________________________________ > linux-security-module mailing list > linux-security-moduleat_private > http://mail.wirex.com/mailman/listinfo/linux-security-module > |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Tue May 22 2001 - 14:16:49 PDT