RE: Making forward progress

dwheelerat_private

It appears to me that there's increasing unrest with the restrictive
hook approach, with a number of problems being noted about it.

However, many seem to believe that removing _all_ existing DAC checks
from the kernel isn't allowable.  And although various arguments have
been made, in my mind the major _advantage_ of restrictive hooks is their
ease of verifiability.

Let's examine a form we've looked at before:

  retval = (current-DAC-check);
  if (hook(retval, ...)) ...

This has several advantages:
1. The DAC check is still in the kernel code.  That way, the "default"
   is clearly stated, and there's not problem with duplicate code that tries
   to emulate what the kernel "usually does".
2. In many cases, this won't require many changes from what's done now,
   so I don't think it'd be too hard to switch from what's here now.
3. Verification of security modules is the main advantage of restrictive
   hooks, though as noted, it turns out to be fairly easy to unintentionally
   mess things up anyway.  However, if all hooks start like this in a module:

    if (retval) return retval;

   Then you have a "restrictive-only" module.  This is trivial to verify
   by hand; at most, you need to check ~140 entries for a sophisticated
   security module.

   This could even be checked automatically.  Yes, this is something that
   needs checking, but hopefully no one is going to insert
   unchecked security modules into critical systems :-).

Perhaps there are places in the code where it makes little sense to
permit a DAC override.  In which case, don't pass a "ret", and the
hook is restrictive (instead of authoritative).  That means that you'll
need to know, for each hook, if it's restrictive or authoritative,
which can be determined from its prototype.

This _does_ mean that, performance-wise, DAC checks always execute first.
However, the kernel developers will want the COMMON case ("no fancy
security module") to be fast, and paying for a few more cycles isn't
likely to be a problem on systems worrying about advanced security
mechanisms.  Indeed, on most processors, the function call
will almost certainly swamp any other performance payment you make.
For the case of "the DAC security values are on tape", perhaps such
DAC values should be implemented via a stackable security module instead
the filesystem.

However, from the point-of-view that some standards etc. say "check A then B",
then from the user's point-of-view that's what happened
(even if B is computed first, the result of A is authoritative...
I'm ignoring the CPU covert channel).

IIRC, on x86's, up to 4 arguments are usually passed via registers using gcc,
so >4 arguments passed are somewhat slower.  Not sure if that'll make
much difference here.

Stephen Smalley said:
>Alternative DAC mechanisms can be implemented using LSM - you simply
>implement your new DAC logic in the module and if you want your logic to
>completely replace the old DAC logic, your module uses the capable hook
>to override the old DAC logic.

This is true, though if people really want to do this, restrictive hooks
are a terrible way to do it.

Anyway, my two cents.

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