[PATCH] builtin stack support

[PATCH] builtin stack support

[Bastian Blank]

[-- Attachment #1.1: Type: text/plain, Size: 1547 bytes --]

hi folks

the following patch
- modifies the security modules registering code to built a stack of
  modules themself
- changes the internal interface of the security functions to get a
  pointer to that stack
- the dummy functions always traverse through the stack
- register the dummy functions as a special security module
- drop the cap_* declaration
- drop mod_(un)reg_security
- add a name parameter to (un)register_security

missing things
- register_security isn't called, it may decide if it allowes the other
  module to be stacked together.

advantages
- it is possible to stack modules together without special support by
  the modules
- add functions which will be handled by a non standard module without
  need to modify the standard one

problems
- abi change, change of the security inline functions
- root_plug is currently unbuildable because the exports of the cap_*
  functions are dropped, it don't need to use them directly
- if the modules don't define a function, the call always travers
  through the stack until it hits the dummy module
- more pointer needs to be dereferences, more parameter

future enhancements
- define different stacks for different types of functions (may be
  faster)

i currently write a kernel extension which needs a security module
themself and i want to be able to load this module regardless of the
actual loaded modules.

i know that the patch is large, it needs to change one thing many times.

bastian

-- 
Captain's Log, star date 21:34.5...

[-- Attachment #1.2: diff.gz --]
[-- Type: application/octet-stream, Size: 14248 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] builtin stack support

[Greg KH]

On Fri, Jun 20, 2003 at 09:50:51PM +0200, Bastian Blank wrote:
> hi folks

I'd suggest CC: the lsm mailing list, they might have some comments
about this.

> the following patch

Please don't compress patches, it's a pain to read them.

> - modifies the security modules registering code to built a stack of
>   modules themself
> - changes the internal interface of the security functions to get a
>   pointer to that stack
> - the dummy functions always traverse through the stack
> - register the dummy functions as a special security module
> - drop the cap_* declaration
> - drop mod_(un)reg_security
> - add a name parameter to (un)register_security
> 
> missing things
> - register_security isn't called, it may decide if it allowes the other
>   module to be stacked together.
> 
> advantages
> - it is possible to stack modules together without special support by
>   the modules
> - add functions which will be handled by a non standard module without
>   need to modify the standard one
> 
> problems
> - abi change, change of the security inline functions
> - root_plug is currently unbuildable because the exports of the cap_*
>   functions are dropped, it don't need to use them directly

Why not fix this, as you just broke it :)

> - if the modules don't define a function, the call always travers
>   through the stack until it hits the dummy module
> - more pointer needs to be dereferences, more parameter

How does the performance of this work out, if you only have 1 security
module?  In my opinion, preformance should not drop, unless you want to
stack modules.

And did you see the previous stacker lsm module?  What advantage does
this patch over that one?

thanks,

greg k-h

Re: [PATCH] builtin stack support

[Crispin Cowan]

Greg KH wrote:

>On Fri, Jun 20, 2003 at 09:50:51PM +0200, Bastian Blank wrote:
>  
>
>>hi folks
>>    
>>
>I'd suggest CC: the lsm mailing list, they might have some comments
>about this.
>
FYI, Chris Wright (one of the main LSM developers) left for a week's 
vacation today. This patch appears to be a major change in how LSM 
works, and I suspect Chris will want some time to consider it. So don't 
be terribly surprised if not much happens until June 30.

However, Chris also told me that he took his laptop with him. He might 
choose to take some of his vacation time to look at this.

>>- if the modules don't define a function, the call always travers
>>  through the stack until it hits the dummy module
>>- more pointer needs to be dereferences, more parameter
>>    
>>
>How does the performance of this work out, if you only have 1 security
>module?  In my opinion, preformance should not drop, unless you want to
>stack modules.
>
I agree with Greg. We deliberately did not design in explicit support. 
The priority scheme was:

   1. Have the least impact possible on kernels not using modules.
   2. Have the best performance possible for a single module.
   3. Push work for stacking modules onto module writers who want to stack.


>And did you see the previous stacker lsm module?  What advantage does
>this patch over that one?
>
The problem with module composition is that it is sometimes straight 
forward, but often problematic, and in some cases impossible. You 
*cannot* provide support for module composition in the general case; at 
best it will work sometimes. Wheeler's existing Stacker module 
encapsulates the logistics for supporting module composition in the 
simple cases, and module writers *need* to hack it themselves in the 
harder cases.

Crispin

-- 
Crispin Cowan, Ph.D.           http://immunix.com/~crispin/
Chief Scientist, Immunix       http://immunix.com
            http://www.immunix.com/shop/