Re: OLS Bof info

lachlanat_private

Crispin Cowan wrote:
> richard offer wrote:
> 
>> * chrisat_private at '7/2/02 12:54 PM -0700'
>> * No, we don't want this.  Kernel subsystems are particular to kernel
>> * version.  If you have these needs you are porting to kernel version Z.
>>
>> So we should make it clear for module writers that LSM version X on 
>> 2.4 may have a different set of hooks than LSM version X on 2.5... 
> 
> 
> I think you guys are talking at cross-purposes.
> 
>    * Chris is saying that modules should be compiled precisely for the
>      kernel they are going into. Linux has never supported anything
>      else. If a slightly newer kernel loads an older module without
>      complaint, it is purely good fortune, but not supported.
>    * Richard is concerned that the 2.4 and 2.5 API's will diverge. That
>      is not the intent. We DO intend to keep the 2.4 and 2.5 LSM APIs
>      consistent. If anything, broad release of a 2.4 version should
>      wait until the 2.5 version is "settled", so that it won't change
>      too rapidly once the 2.4 version is released.
> 
> What this discussion is REALLY about is "safe" stub filling:
> 
>    * LSM has 150+ functions to populate. They *all* have to be
>      populated, which can be tedious if you only want to mediate a few
>      hooks.
>    * Brute force solution: make the module programmer do it by hand.
>    * Semi-automatic solution: some kind of mechanism that populates all
>      of the stubs that you didn't fill in yourself.
> 
> *Risk:* what if the kernel adds a new hook, and you (module writer) 
> don't notice? And it's important to your security model, i.e. Chris adds 
> the "kick Richard's module in the nads? Y/N" hook :) and Richard doesn't 
> notice.
> 
>    * with the "manual fill" method, Richard's module won't
>      compile/load, so he'll notice
>    * with the auto method, Richard may well "port" is module to the new
>      interface and not notice the new critical issue :)
If we have register_security() fill the security_ops structure
with stubs prior to incorporating the module's hooks and then
return the final number of stubs used (ie total hooks - module
supplied hooks) then if that number changes the module maintainer
knows that a new hook has been added.

We could also allow the module to determine the default policy
of the stub hooks by having all the stubs that can return an
error to return 'sec_default' and the module can configure
sec_default to be 0, -EPERM, -EACCES, etc.  If sec_default is
set to return an error then new hooks will not open security
holes but it will mean that hooks not relevant to the security
module will also fail so it's not all that helpful.

> 
> Crispin, who's just having fun with the personal pronouns and doesn't 
> really mean anything by it :)
> 

-- 
Lachlan McIlroy

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module