Greg KH sagely proclaimed:
> I also fixed up the owlsm module, based on the fact that we don't have
> to have a bunch of "NULL" functions around anymore. But in doing that I
> realized that it doesn't have a lot of the default capabilities
> functionality in it. Now that the capability functions are exported,
> this is easy to add, if it's wanted.
>
> So should I add this? Or is owlsm just a "test" module that will never
> be added to the main kernel tree?
Yes, yes, yes! Please add capability support to owlsm, so that people can
"just use it". I think that owlsm should go into the mainline
Linux tree, since it's really quite useful. It simply prevents some
activities that are _known_ to be dangerous, and by enabling it, people
can improve the security of their boxes at little cost.
Besides, if there's an LSM module placed in the mainline kernel,
it's a lot easier to justify the existance of the LSM in the first place.
While you're making these changes,
can you make it "stack" more cleanly, so that when I update the
"stacker" module owlsm will play nicely? Basically, you need to
(1) set secondary=1 BEFORE calling mod_reg_security(), _not_ afterwards, and
(2) in areas where you'll call (or reimplement) the capability module, do an
"if (secondary) {return capability_result()} else {return 0; /* no err */}".
Why? Well, for point (1),
you need to set the secondary value (and any other state) before registering
to eliminate a race condition (basically, the module needs to be fully
initialized before registering it). For point (2),
the check for the value of secondary
means that, if the module is stacked, it will NOT try to call the
capability module - instead, it will let the stacking module determine
if or when to call it. This is especially critical for the capable() call,
but please do it uniformly.
Here's an owlsm_init done this way:
static int secondary;
/*....*/
static int __init owlsm_init (void)
{
/* register ourselves with the security framework */
if (register_security (&owlsm_ops)) {
printk (KERN_INFO
"Failure registering owlsm module with the kernel\n");
/* try registering with primary module */
/* NOTE: The module must be completely ready to go
* before calling mod_reg_security. In particular, to avoid
* a race condition, we must set "secondary" and
* and "pseudo_dummy" BEFORE calling mod_reg_security */
secondary = 1;
if (mod_reg_security (MY_NAME, &owlsm_ops)) {
printk (KERN_INFO "Failure registering owlsm module "
"with primary security module.\n");
return -EINVAL;
}
}
printk(KERN_INFO "owlsm LSM initialized\n");
return 0;
}
Oh, and here's lengthy documentation from my stacking.c code that
discusses this:
/*
* 1. To stack at all, a module needs to call
* mod_reg_security(); typically this is done if register_security()
* fails (see capability.c for an example of how to do this).
* Usually if an LSM module is loaded as a secondary module, it should
* set a flag named "secondary". Modules should normally set
* secondary to true and any other variable used by the LSM module BEFORE
* calling mod_reg_security() to avoid a race condition.
* DO NOT call mod_reg_security() first, followed by secondary = 1;
* if you do, there will be a period of time where the module is loaded
* as a secondary module BUT the value of "secondary" will make the module
* THINK that it's not a secondary module. This race may cause
* various terrible effects. So, be sure to set secondary before calling
* mod_reg_security().
*
* 2. If you want your LSM module to have maximum flexibility when
* stacked, you should NOT duplicate the nontrivial actions of the
* "dummy" or "capability" module whenever your module is loaded as a stacked
* module (e.g., its "secondary" flag is on); if you duplicate those actions,
* this will limit the amount of control an administrator has over
* a stacked system.
* By nontrivial, I mean anything other than "return" or "return 0".
* Instead, if "secondary" is on, the LSM module should do ONLY the checks
* unique to the LSM module (forbid anything else for capable(), and
* permit everything for the rest of the hooks).
* This is MOST important for the capable()
* call; since capable() is an authoritative hook, anything it allows will be
* allowed no matter what. Unless your LSM module determines that a given
* capability must be raised according to its own rules, in your LSM module's
* hook for capable() return an error if "secondary" is on. Also examine all
* hooks which have nontrivial implementations in dummy.c or capability.c.
* So, look carefully at the LSM module's implementation of the following
* hooks: capable, netlink_send, netlink_recv, task_reparent_to_init, and
* ip_decode_options (these are calls that have nontrivial implementations
* in "dummy.c"). Also look carefully at these hooks:
* ptrace, capget, capset_check, capset_set, bprm_set_security,
* bprm_compute_creds, task_post_setuid, kmod_set_label, task_reparent_to_init,
* ip_decode_options (these have nontrivial implementations in "capability.c").
*
* 3. DOCUMENT CLEARLY for your LSM module any requirements/limitations
* on stacking the module, to help administrators determine if they can
* stack your module with other modules.
* If the module uses or does not use any
* of the (void*) security fields in the kernel structures
* (if you use them, please document WHICH ones). That way,
* administrators can quickly detect certain kinds of conflicts between
* stacked modules. Document whether or not the module re-implements
* the capability or dummy module when loaded as a secondary module.
* And, if you know that certain modules WILL work
* together (e.g., because they're designed to lock correctly and use
* the same meaning for certain security fields), document that too.
* Also document any deactivation requirements.
*/
--- David A. Wheeler
dwheelerat_private
_______________________________________________
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 Dec 18 2002 - 18:52:10 PST