RE: Making forward progress

From: Stephen Smalley (sdsat_private)
Date: Fri Aug 03 2001 - 09:16:53 PDT

  • Next message: Stephen Smalley: "Re: Making forward progress"

    On Fri, 3 Aug 2001, KRAMER,STEVEN (HP-USA,ex1) wrote:
    > To be fair, the translation of the restrictive hooks to before the DAC 
    > checks would continue to satisfy the needs of all of the list above except
    > SubDomain, and in its place would be SGI.  (That is, the 
    > proposition isn't that all the above projects succeed vs. SGI succeeding,
    > but the translation will affect only 2 of the projects.)  On the
    > other hand, the change away from restrictive hooks would allow all of the 
    > projects to succeed.
    SELinux has an auditing/logging facility and a development mode 
    analagous to the SubDomain bitch mode for assisting us in
    creating policy configurations.  So we also would prefer to
    avoid logging spurious denials that are handled by DAC. 
    And my impression is that SGI hasn't made its case that
    it truly needs the hooks before the DAC logic for MAC.
    As others have observed, returning different error codes
    is the module's problem (and an application's nightmare).
    From a restrictive perspective, it makes sense for all of the
    hooks to occur after the existing kernel checks.  The placement
    of the hooks and the use of restrictive hooks doesn't guarantee
    "simple assurance", but it does make it easier to verify.
    > Maybe what's needed is a principle that states that the inclusion of a
    > project always comes before potential performance problems in any one
    > (or plurality?) of projects.
    This should only be true for projects that fall within the
    scope of Linus' mandate.  It doesn't mean that we should try
    to accomodate every kind of kernel security project that
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Aug 03 2001 - 09:18:37 PDT