Re: MAC before DAC vs DAC before MAC

offerat_private

* frm dawat_private "07/25/01 21:10:07 +0000" | sed '1,$s/^/*
/'
*
* First, one quibble: This is not about the order of MAC and DAC,
* but rather about in-module checks vs. in-kernel checks.  

You're right, my mistake for clouding the waters.

* 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.
* 
* 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.
* 
* 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.

[snip example code ]

* Does this work?

At first glance it looks like it will fix the audit issue, definetly
something that we should investigate more.

It doesn't get over the issue of performance (module faster than kernel).
But we can probably live with that.

It also means the placement is more critcal, we'd need to look over every
existing hook to ensure that it isn't being jumper over on an error.

richard.

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

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