Re: [PATCH 1/3] IMA: move read/write counters into struct inode

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

 On 10/22/2010 1:48 AM, Ingo Molnar wrote:
> * Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>>  On 10/20/2010 8:15 AM, Ingo Molnar wrote:
>>> * Eric Paris <eparis@redhat.com> wrote:
>>>
>>>> On Wed, 2010-10-20 at 16:38 +0200, Ingo Molnar wrote:
>>>>> * Eric Paris <eparis@redhat.com> wrote:
>>>>>
>>>>>> Executive summary of the day's work:
>>>>>> Yesterday morning: 944 bytes per inode in core
>>>>>> Yesterday night: 24 bytes per inode in core
>>>>>> Tonight: 4 bytes per inode in core.
>>>>>>
>>>>>> That's a x236 time reduction in memory usage.  No I didn't even start looking 
>>>>>> at a freezer.  Which could bring that 4 down to 0, but would add a scalability 
>>>>>> penalty on all inodes when IMA was enabled.
>>>>> Why not use inode->i_security intelligently? That already exists so that way 
>>>>> it's 0 bytes.
>>>>>
>>>>> Thanks,
>>>> It still wouldn't be 0 bytes since there would be a 1-1 mapping from inode to 
>>>> i_security structs. [...]
>>> Only for IMA-affected files, right?
>>>
>>> My point is to keep it 0 overhead for the _non IMA common case_.
>>>
>>>> The real reason I don't pursue this route is because of the litany of different 
>>>> ways this pointer is used in different LSMs (or not used at all.)  And we all know 
>>>> that LSM authors aren't known for seeing the world the same way as each other.  As 
>>>> a maintainer of one of those LSMs even I'm scared to try pushing that forward....
>>> Ugh. That's a perfect reason to do it exactly like i suggested.
>> If you would like to make a proposal on LSM stacking other than the traditional 
>> "rip the LSM out" I am sure that everyone in the IMA, SELinux, TOMOYO, AppArmor 
>> and Smack communities would be happy to have a look. Short of having a viable 
>> mechanism for multiple LSMs to coexist IMA needs its separate space. Yes, people 
>> do use both IMA and LSMs on the same machine at the same time.
> Yes, that's the essence of what i suggested: if various security concepts can be 
> present at once then inode->security should not be a stupid pointer to a single, 
> exclusive data structure (because that hardwires a "only a single security subsystem 
> active" assumption), but should be a pointer to a linked list of security structures 
> - as many as there are security subsystems interested in that inode.

Glad to see support for an LSM module stacker (modulator, combiner, ...)
growing. All we really need to do is get someone a case of the beverage
of their choice and turn them loose on the problem. I think that the few
anti-stacking holdouts (I was one, but converted a couple years ago) can
be swayed by a reasonable implementation. It won't be easy, there are
plenty of problems that need to be solved, but anyone who wants easy
should stick to developing web portals and stay out of the kernel.

>  
> Thanks,
>
> 	Ingo