Re: MAC before DAC vs DAC before MAC

crispinat_private

David Wagner wrote:

> First, one quibble: This is not about the order of MAC and DAC, but rather
> about in-module checks vs. in-kernel checks.  Although in your favorite
> policy, the in-kernel code is DAC and your module does only MAC, these
> concepts are orthogonal, and there's nothing that says they will always
> line up like this.  Other people's modules might do DAC, or indeed the
> distinction between DAC and MAC might not even be meaningful in some
> cases.

I totally agree with this point.  I thought I said it at some point, but I
may have just typed it up and deleted it as distracting from the point I was
trying to make at the time.

Caveat: the one reason to think of hooks as MAC is that LSM is the only
place you can do MAC things.  Modules can be either DAC or MAC, while the
in-kernel stuff is strictly DAC.

> That said, the main technical reason I heard you say about why you prefer
> in-module checks before the in-kernel checks is for audit: It is a higher
> priority to record failures of in-module policy than to record failures of
> base-kernel-enforced policy.  Meanwhile, in SubDomain, those priorities
> are reversed.

I find the duality of the situation intriguing, and wonder if there mightn't
be a clever solution here somewhere.  Both SubDomain and Audit want the
order they want to reduce the amount of noise in their audit trails:

   * SubDomain wants the DAC checks done first, so that access requests that
     will fail MAC (and thus make unwanted noise) get filtered out if they
     also fail DAC.
   * SGI's Audit wants to turn off auditing on DAC because its too noisy,
     and only audit MAC failures.

The part I don't get is why it is a problem to fail to audit an access that
fails DAC that would have also failed MAC.  If DAC failures are too noisy to
be interesting, then why is a DAC failure that would also fail MAC more
interesting?

> So, let me propose a possible compromise solution.  Has anyone thought
> about doing something like the following?
>    int rv = 0;
>    if (... in-kernel check fails...)
>      rv = -EPERM;
>    rv = security_ops->hook(rv, ...);
>    if (rv < 0)
>      return rv;
> This way, the module gets to see both whether the in-kernel checks
> succeeded or not and whether the in-module checks succeeded or not, and
> then the module can set the policy on which is to take priority.

That looks like an authoritative hook to me.  Bad logic in the module could
result in an override of kernel DAC logic.

I've argued long & hard against permissive and authoritative hooks.  I'll
have to think about which one I want more: the simple assurance property, or
DAC/MAC sequence the way I want it.

What do other people think?  There was a mixed bag on the
permissive/restrictive question:

   * Do people who wanted restrictive hooks find the DAC/MAC sequence to be
     a compelling reason to give up the simple assurance property?
   * Do people who wanted authoritative hooks find the above form of hook to
     be satisfying?

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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