Re: 2001_05_04 patch against 2.4.4

chrisat_private

* Chris Evans (chrisat_private) wrote:
> 
> On Fri, 4 May 2001, Greg KH wrote:
> 
> > On Fri, May 04, 2001 at 08:53:31PM +0100, Chris Evans wrote:
> > >
> > > Is there an up to date list of access points where hooks exist (or will
> > > exist)?
> >
> > Right now the only documentation like this is the code.  There is an
> 
> Hey,
> 
> No worries - I don't mind reading code. After all, it is the authorative
> source of what is going on (and docs sometimes are not ;-)
> 
> I'm trying to find the time to catch up reading the list archives, but
> time seems to be in short supply. From a high level, what kernel
> primitives have you decided to hook (or not?)

I'd suggest looking at the security.h file.  It _is_ the current interface,
and shows what is being hooked.  The hooks fall loosely into categories by
kernel object (with some leftover stuff, of course ;-).  Modification of
kernel object data is protected with a hook, and some requests for read
access to kernel object data have been made (although I believe none have
been incorporated yet).

The mission is to develop a well-abstracted interface that can be implemented
by a variety of security models.  The proof of concept security model we are
pushing into a module is Privs.  Calls to capable() are being slowly replaced
with (hopefully well-abstracted ;-) hooks.  So rather than, do I have
CAP_SYS_ADMIN, a hook might be can I mount this device with these flags,
etc.

Hooks that create inode objects have been given post-action hooks so
security models can synchronize internal state.  We are expecting fewer
post-action hooks than action hooks (right now).  We are discussing the need
for pre-action hooks as well (separate from action access hooks).  So in
some code paths we may see: can I do this, I'm about to do this, I just did
this and the results were...

The hook interface is basically a structure of funcition pointers.  Some of
the function pointers are directly in the security_operations structure
(those that fit in the miscellaneous catergory).  The rest are grouped by
kernel object (roughly).  This was done solely to make it easier to
manage the interface while developing it.  When all is said and done, the
extra layer of indirection (i.e. security_ops->task_ops->kill()) will likely
give way to performance needs.

Hope this helps!
-chris

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