Quoting Hao Xu ([EMAIL PROTECTED]):
> I've been thinking about LSM stacker module these a few days. Sharing
> the void *security between multiple secondary modules is tough, real tough.
Given that you are the author of the three modules you want to stack, it
really shouldn't be.
Define a convention for your three modules. I.e. always point
tsk->security = kmalloc(3*sizeof(void *), GFP_KERNEL);
where by convention each module knows which of the three pointers it
uses to attach its own data to.
> The only problem that haunts me now is:
> How to deal with the incore kernel object security data allocated by a
> secondary module after unloading this module?
First question is, do you expect to be unloading these modules, really?
If these are serious security modules I should think that real users
would want them compiled into the kernel.
But if you really need to be able to unload them, you can, for instance,
connect all the security structures your module has defined with a
list)_head. On unload, walk that list_head and free the objects. Or,
put a version number in there, so that when the user reloads the module,
when it runs accross an already loaded inode, it sees the old version
number and updates the info or just frees and reinstantiates it.
> For tasks, I think we can do it this way:
>
> /* assume the name of the secondary module that is being unloaded is aaa */
> for_each_process(p) {
> /* swap the p->security for aaa */
> aaa_ops->task_free_security(p);
> /* swap it back */
> }
>
> What do you think? And what about inodes, bprms and others?
>
>
> Thanks!
>
> hao
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
