Re: [PATCH v12 3/9] LSM: Multiple concurrent LSMs

[Casey Schaufler <casey@schaufler-ca.com>]

On 1/21/2013 3:19 PM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> On 1/21/2013 4:42 AM, Tetsuo Handa wrote:
>>> Below is what I think we need for "current v12 patchset" + "LKM-based LSM
>>> support" + "Require a valid ->order value to all LSM" approach.
>>> What other mechanism we are missing?
>> The big trouble is cleaning up blobs that an LSM has allocated
>> at the time an LSM is unloaded. I am only including the ability
>> to unregister via reset_security_ops (which I plan to rename,
>> more on that later) because SELinux depends on it.
> Right. I agree that it is difficult to clean up blobs that an LSM has allocated
> at the time an LSM is unloaded. But not all LSM modules want to allocate blobs.

True enough, but the one example we have of LSM unloading is going
to leave droppings. I don't want to go anywhere near module unloading,
even for LSMs that don't use the official mechanisms, without a story
on how they're going to get cleaned up.

>> I'm renaming reset_security_ops to security_module_disable to match
>> up with security_module_enable. I know it's unnecessary, but I think
>> it's the right thing to do.
> I think that unregister_security() is better named, for we want both
> security_module_enable() and register_security() (since built-in LSM modules in
> Ubuntu kernels need to be able to distinguish whether to try to load or not).

I'm addressing this is v13 without introducing unregister_security.
Patch coming later this week most likely.

> I'm OK to rename reset_security_ops() to security_module_disable() if
> security_module_enable() is changed to return "0 or -ve" so that
> security_module_enable() can return the caller the reason of registration
> failure.

I'm doing that in v13 as well.

>>> +EXPORT_SYMBOL_GPL(security_module_enable);
>> I am disinclined to put in what might appear to be support
>> for dynamic security modules when I'm not yet willing to
>> sign up for that.
> I'm ready to convert TOMOYO into LKM-based LSM and TOMOYO-like modules as well.
> Sorry, I still have not understood what other mechanism we are missing...

I'm not sure that we're missing anything beyond locking
(as you have pointed out) and cleaning up, which you're
less concerned about than I. What I am *not* ready to do
is stand up and say that I believe all the bases are covered.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.