Re: 2001_05_04 patch against 2.4.4

From: Chris Wright (chrisat_private)
Date: Fri May 04 2001 - 16:04:26 PDT

  • Next message: Mariusz Woloszyn: "Re: 2001_05_04 patch against 2.4.4"

    * 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,
    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!
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri May 04 2001 - 16:10:54 PDT