Re: The Demise of Simple Assurance?

From: jmjonesat_private
Date: Wed Aug 01 2001 - 15:53:47 PDT

  • Next message: Valdis.Kletnieksat_private: "Re: The Demise of Simple Assurance?"

    On Tue, 31 Jul 2001, Crispin Cowan wrote:
    > Here's some hook placement issues that do come up, following a discussion with Chris
    > Wright:
    I assume this is the list of concerns to which you referred.  I apologize
    if it is not.
    >    * MAC/DAC sequence:  making the hooks authoritative means universally
    >      doing the
    >      DAC checks first.  To be authoritative, the hook must be the very
    >      last thing
    >      checked before access proceeds.  SGI may not like this.
    Stage I "sales-worthiness" requires this.  I don't LIKE it, but I haven't
    seen any argument that pushes it over the fence to "well, we gotta do it
    now", other than "it's the right thing to do", which would sell ME, but is
    a bit vague, imho, to build a consensus on: right and wrong being
    contextually variable things.
    Of course, the KD's may slam us against a wall and ask why we didn't do
    this.  Something to consider, even briefly.  Especially since we've said
    it here and they're almost certainly listening.
    If this interface fails to get accepted (a real possibility), we're
    all hosed.  I think resolving the DAC/MAC MAC/DAC issue NOW is impossible,
    and while it's an important issue, authoritative hooks lay the groundwork
    for solving it later... the magnitude of "later" being arguable.
    >    * Being fully authoritative:  there are code paths where an early DAC
    >      check that fails short circuits out of the kernel.  With our
    >      current hook placement, we
    >      won't catch all of those short circuits out of the kernel. 
    >      Therefore, the hooks
    >      won't really be universally authoritative, unless we go place a lot
    >      more hooks. 
    >      Chris is unsure of how many additional hooks would need to be placed.
    "unless we place a LOT" vs. "unsure of how many additional".  I see a few
    places where we might have to add hooks, maybe more than a few but far
    less than a "lot".  I'm not convinced the "new" hooks will outnumber the
    current ones.  Small modifications to the kernel code that concentrate the
    results with a jump will probably suffice, or just scanning for returns
    and placing a hook there that "processes" the return value in many places. 
    Something fewer than 100, I think (that being the current number of new
    hooks required to implement a before AND after model.) Maybe FAR fewer.
    There are 400 people on this list.  If we move to authoritative, require
    each evaluate 1/4 hook... the manpower is minimal. :)  FLIPPANT, I know,
    but I suspect a few will dig-in to re-locate many, thereby relieving most
    of the community of the effort. (( In Essence: Sorry Chris, We'll help all
    we can. ))
    > Crispin
    > --
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc.
    > Security Hardened Linux Distribution:
    > Available for purchase:
    J. Melvin Jones
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 15:54:39 PDT