permissive vs. restrictive issue and solutions...

From: Chris Wright (chrisat_private)
Date: Thu May 31 2001 - 18:11:20 PDT

  • Next message: Crispin Cowan: "Re: permissive vs. restrictive issue and solutions..."

    I just wanted to summarize the current proposals for building a
    consisitent hook interface that solves the needs of restrictive modules
    (arguably most) and permissive modules (i.e. capabilities).
    I think we can agree on the need to provide a way for modules to express
    either restrictive or permissive policies.  Following are three
    alternatives that have been suggested with my comments added.
    1.  Add separate hooks to explicitly allow both permissive and
    restrictive policies.
      this allows for flexibility at the expense of simplicity in the interface
      (as well as the kernel code since we'd be adding the hooks).
    2. Maintain current set of hooks and push logic out of the kernel and into
    the module to avoid placing hooks in compound conditionals.  
      this allows for flexibility at the expense of rebuilding kernel logic in
      the module.  really calls for stacking modules.  looks like an invasive
      kernel patch (may be a hard sell).
    3. Maintain current set of hooks and keep logic in the kernel.  Add an
    argument to hooks to show whether the kernel was going allow or deny the
      this allows for flexibility, but i'm not sure it builds a consistent
      interface.  hooks that we've added beyond capabilities are not always in
      conjunction with kernel restriction tests.  guess we can always pass in
      "kernel would've allowed this" in those cases to build consistency.
    i guess i prefer the approach in option 2, but perhaps option 3 is more
    likely to be accepted in to the kernel.
    thoughts from the list?  other options?
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 31 2001 - 18:14:24 PDT