Re: Design scope of a security policy module

chrisat_private

* Henrı Şór Baldursson (henry@f-prot.com) wrote:
> 	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. 

Don't forget mmap()...

> 	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. 

Indeed, you'd have to do something like this to make it general, but I'm
still not fully convinced that this isn't over engineering.

> 	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.

The way you describe it is roughly what I'd expect to see, and is why I
think it may be simpler for modules to just do exactly what they need.
If you work up a patch we can discuss something concrete.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module