On Wed, 19 Sep 2001, Chris Wright wrote: > hmm, i think i like the idea of pushing the call to be inside free_module, > but since it returns void maybe just before these calls. this gives the > lsm module the opportunity to care about the actual module being unloaded, > (in the null, module reaping case) not just the fact that _a_ module is > being unloaded (which is already sort of protected, as you mentioned, > by the capable(CAP_SYS_MODULE) call). passing the module structure to > the delete_module call suggests the ability to tag a security attribute > to the module struct (which i haven't added below). > > something like this (the NULL case needs some work -- what to do if > error: continue, break, return 0, return error, etc --, this is just for > conversation's sake): This looks good. I think that doing the continue is the right course of action. Also, I suppose that we could remove the name parameter from the init_module hook, since it is redundant with the module parameter. Adding a security field to the module structure might be interesting, but I'm not sure what the basis for determining the tag would be. When we looked at kernel modules for SELinux, we originally hoped to perform a permission check based on the label of the file from which the module was stored (to check its integrity), but the file doesn't seem to be available to the kernel since the utility handles the loading. I suppose you might do some kind of tagging based on a hash of the module. -- Stephen D. Smalley, NAI Labs ssmalleyat_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 : Thu Sep 20 2001 - 07:14:34 PDT