Re: 2.4 Ready list - Kernel Hooks

Re: 2.4 Ready list - Kernel Hooks

[Richard J Moore]

Greg KH wrote:
>Please read the LSM documentation for more information about this.  It
>can be found in the kernel at:
>            Documentation/DocBook/lsm.*
>and there are a number of USENIX and OLS papers about different aspects
>of the project at:


Thanks Greg. I'll check out the doc. I do remember posting the LSM mailing
list about kernel hooks, but as I recall there was no response. I assumed
that the hooking mechanism was not the focus of attention - that was
18months ago. A few weeks ago Suparna told me LSM had been enquiring about
kernel hooks - never heard the outcome though.

Richard

Re: 2.4 Ready list - Kernel Hooks

[Greg KH]

On Thu, Oct 24, 2002 at 05:38:12PM +0100, Richard J Moore wrote:
> 
> A few weeks ago Suparna told me LSM had been enquiring about kernel
> hooks - never heard the outcome though.

Wrong type of "hooks".  Ours would not work for what you are stating you
need to do, sorry.

thanks,

greg k-h

Re: 2.5 Ready list - Kernel Hooks

[Suparna Bhattacharya]

On Thu, Oct 24, 2002 at 05:06:44PM +0000, Greg KH wrote:
> On Thu, Oct 24, 2002 at 05:38:12PM +0100, Richard J Moore wrote:
> > 
> > A few weeks ago Suparna told me LSM had been enquiring about kernel
> > hooks - never heard the outcome though.
> 
> Wrong type of "hooks".  Ours would not work for what you are stating you
> need to do, sorry.

Backing up a bit, to the more basic question raised briefly 
at the kernel summit. Does it make sense to use a common underlying 
hooking mechanism for the various kinds of subsystems 
that use some form of hooks ? Or are the requirements radically 
different enough that it is better for each to devise its own ?

The main advantage of a common mechanism (needn't necessarily be 
kernel hooks, by the way) is scope for single source optimization 
(including arch specific optimizations where feasible) and a 
common scheme of management. These are reasons why LTT, for
example might make use kernel hooks.

The downside of course is that one solution may not suit all,
and in some cases (where the above aspects are not critical) 
people might prefer as a matter of taste to have explicit subsystem 
specific calls that clearly indicate the kind of component using the 
hooks. (Am wondering if this is one of the reasons why LSM  
would prefer not to link up with kernel hooks. Is that it ?)

A few clarifications with regard to Kernel hooks, Dprobes and LSM.

To reiterate Vamsi's point, Dprobes and Kernel Hooks are different.
Dprobes is meant for probing on demand and based on a breakpointing 
mechanism, and yes, it isn't at all meant for the kinds of things 
that LSM is doing. 

Kernel hooks are really more like notifiers meant for fast or 
frequently accessed paths, optimized for minimal overhead when 
the hooks are not active. These hooks can be placed at any code 
location and the hook operation can be passed local variables 
directly as arguments (no need to build up a structure etc). 

The component which registers operations could be part of the 
kernel or in a GPL'ed kernel module. Just like notifiers, the call
to the hooks has to be there beforehand in the kernel at necessary 
locations.

So this is really very similar in effect to invoking a function 
pointer (from a vector of hook operations), with a desired set of 
parameters. The main difference is in the mechanism underneath
in terms of how it performs when the operations are dummy (i.e.
not really active).

Given this, situations where one might investigate the kernel
hooks option:
1. Hooks/function pointers called in frequently hit paths
2. Hook operations that may largely be dummy/dormant in most 
   typical situations

BTW, if the function pointers are context based (i.e. object
specific where the object is a runtime parameter) then one
couldn't use kernel location hooks (LSM security operations 
are in their own table though, not object specific like inode 
operations, right ?)

At Ottawa, when LSM was being presented there was some mention
of optimized hooking. If I recall correctly the security_ops 
vector had around 60+ operations/hooks and it did seem like 
a given security module might not be using all the hooks 
(capability.c probably uses only one-fifth of the hooks). 

My perspective on LSM is limited, so could you tell me if this 
is the common pattern on most linux installations i.e. a large 
percentage of the hooks being inactive/dummy (condition 2
above) ?  Or do you expect all the 68 hooks to be in-use in 
general by some module or the other ? 

Richard, 
IIRC Chris Wright had (shortly after the kernel summit) 
asked me for a reference to the kernel hooks site, but we 
really didn't get to discuss anything subsequently.

Now, looking at the security hook operations themselves, the 
degree of optimization that kernel hooks try to provide 
appears to be unnecessary for all the security hooks 
e.g. some of the operations being mediated are more 
administrative in nature and do not happen frequently, and 
it is likely that many of the other hooks may not be very 
time critical (could someone confirm if this is correct ?). 
So kernel hooks could potentially be used AFAICT (I could be 
missing something, of course), at the same time, I'm not sure 
if condition 2 above applies in this case.

One situation where I see an important difference is in the 
stacking of security modules - kernel hooks do stacking only on 
a per-hook basis, while for LSM this needs to be done on a 
group of hooks owned by a module. Also the LSM design seems to 
leave the implementation of stacking to the discretion of the 
active security module.

Regards
Suparna

> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Labs, India

Re: 2.5 Ready list - Kernel Hooks

[Greg KH]

On Fri, Oct 25, 2002 at 03:49:22PM +0530, Suparna Bhattacharya wrote:
> 
> The downside of course is that one solution may not suit all,
> and in some cases (where the above aspects are not critical) 
> people might prefer as a matter of taste to have explicit subsystem 
> specific calls that clearly indicate the kind of component using the 
> hooks. (Am wondering if this is one of the reasons why LSM  
> would prefer not to link up with kernel hooks. Is that it ?)

Yes, that is one of the main reasons LSM doesn't want to use such a
mechanism.  A simple, explicit, function call is fine for what we need
to do.

thanks,

greg k-h

Re: 2.5 Ready list - Kernel Hooks

[Greg KH]

Oops, forgot to answer your other questions...

On Fri, Oct 25, 2002 at 03:49:22PM +0530, Suparna Bhattacharya wrote:
> 
> So this is really very similar in effect to invoking a function 
> pointer (from a vector of hook operations), with a desired set of 
> parameters. The main difference is in the mechanism underneath
> in terms of how it performs when the operations are dummy (i.e.
> not really active).
> 
> Given this, situations where one might investigate the kernel
> hooks option:
> 1. Hooks/function pointers called in frequently hit paths
> 2. Hook operations that may largely be dummy/dormant in most 
>    typical situations
> 
> BTW, if the function pointers are context based (i.e. object
> specific where the object is a runtime parameter) then one
> couldn't use kernel location hooks (LSM security operations 
> are in their own table though, not object specific like inode 
> operations, right ?)

Yes they are in their own table.

> At Ottawa, when LSM was being presented there was some mention
> of optimized hooking. If I recall correctly the security_ops 
> vector had around 60+ operations/hooks and it did seem like 
> a given security module might not be using all the hooks 
> (capability.c probably uses only one-fifth of the hooks). 
> 
> My perspective on LSM is limited, so could you tell me if this 
> is the common pattern on most linux installations i.e. a large 
> percentage of the hooks being inactive/dummy (condition 2
> above) ?  Or do you expect all the 68 hooks to be in-use in 
> general by some module or the other ? 

I've created simple, useful modules that only use one hook.  But SELinux
uses allmost all of them.  So there is no simple answer for this
question, sorry.

> Now, looking at the security hook operations themselves, the 
> degree of optimization that kernel hooks try to provide 
> appears to be unnecessary for all the security hooks 
> e.g. some of the operations being mediated are more 
> administrative in nature and do not happen frequently, and 
> it is likely that many of the other hooks may not be very 
> time critical (could someone confirm if this is correct ?). 

Many of the LSM hooks are _very_ time critical (every read() call for
example.)

> So kernel hooks could potentially be used AFAICT (I could be 
> missing something, of course), at the same time, I'm not sure 
> if condition 2 above applies in this case.
> 
> One situation where I see an important difference is in the 
> stacking of security modules - kernel hooks do stacking only on 
> a per-hook basis, while for LSM this needs to be done on a 
> group of hooks owned by a module. Also the LSM design seems to 
> leave the implementation of stacking to the discretion of the 
> active security module.

Yes, that is a place of active disagreement among the different LSM
developers.  Some people like it, others don't.  Right now the current
implementation allows you to stack LSM modules if you want to, but you
are not forced to if you don't.

Also, I really don't like the use of the term "hook" for describing the
LSM functions, as you can see how people get confused about this :)
Some other term, like "callback" might be a better term.

thanks,

greg k-h