Re: Design scope of a security policy module

henry@f-prot.com

	Hi Greg. 
	I see your point, and I agree. But I guess I should have clarified some
more. 
	Writing something like a file verdict cache isn't the problem. The
cache could be a finite size array of pointers. On open() and read()
calls, the cache would be checked, to see if this file has been given a
verdict, if not, a verification callback function would be called on it
to supply us with a verdict and a cache entry. Any write() calls would
expunge files from this cache entry. 
	My main concern is that any programming done as a means to accomplish
this would be useless to others that might like to have this same
functionality. Then we would be having many people reimplementing the
same concepts in their respective security policy modules. When as I
understand it, the objective is to supply a framework which one can use
to register _verification_functions_ for objects such as files. So I was
thinking it'd be useful to provide people with some kind of a framework
for adding conditionals or suggestions to their access control criteria.
And to do this in a manner which is sane in the eyes of a programmer. So
that we could have framework-extension modules with some kind of a
uniform way of invokation. 
	I haven't really thought this through yet, but some form of a data
structure being passed to the framework with flags of what type of
functionality a module that has just been linked supports/needs. Then
the framework would work by trying to request a module, and if that
fails, just ignore the instructions in the case of the cache thing, or
fail with an error in some cases. There would be some overhead in
checking for capabilities at each hook.
	I'm sure there are many extension functionality that could be shared
between modules. These are functionalities security policy modules
should utilize, not implement. The benefits of implementing this stuff
in such a centralized manner is so that it's more manageable and all
races and design flaws can be fixed for everyone at the same time.
	So the idea is: a simple non-intrusive framework, but with optional
extensions.
	Bottom line being that any functionality such as caching has no place
in the scope of a security policy module.
	Anyone out there like that idea? If so then I'll consider devising a
prototype.

	Henry. 

On Mon, 2002-11-04 at 16:34, Greg KH wrote: 
> Hm, do you have any specific examples of function calls that should be
> "cached"?  And how do you know if (for example) a file's content's
> hasn't changed from the last time it was accessed, within the existing
> hooks (like the read() hook for example)?
> 
> At first glance I would say that there should not be anything within the
> framework to accomplish such "cacheing" as the framework is nothing but
> a bunch of function calls that would point to your code.  You could
> accomplish the caching just as fast as anything within the framework
> could do.
> 
> A simple example patch for what you are wanting to accomplish would be
> helpful in explaining your concept here.
> 
> thanks,
> 
> greg k-h
> 
> 
-- 
Henrı Şór Baldursson, Linux Developer
FRISK Software International
http://www.f-prot.com
http://aves.f-prot.com