Re: State of Audit Proposal ?

sarnoldat_private

On Fri, Jul 20, 2001 at 03:46:38PM -0700, richard offer wrote:
> Its been a few days now since we released our patch and the discussion has
> died down, so I think its time to summarize.

Always a wise move. :)

> No one ever came back to say why moving the hooks in-front of the DAC
> checks was objectionable, so that seems to be a moot point.

Ah, we've been busy with other issues. I personally don't like this
change for several reasons: first, it assumes that failure is uncommon;
second, it assumes that MAC checks are faster than DAC checks; third,
the rationale for moving MAC before DAC seems thin to me.

I suppose the first and second points are related. If a MAC failure is
for all intents and purposes instant, then the first point doesn't have
much value. So, let us assume for a bit that the MAC checks take a
certain amount of time. As long as the MAC checks are faster than the
DAC checks, it makes sense to put them first from a performance
standpoint. But once the MAC checks are slower than the DAC checks,
performance will suffer by invoking the first winnowing check using MAC.

Considering that the DAC checks are all reasonably quick bit-twiddle
operations, the MAC checks end up needing to be very simple bit-twiddle
operations as well -- or the module will cause a speed penalty
unnecessarily. It is within the range of feasibility to make a call to a
userland process to make the MAC decision. (I think I have read that
OpenBSD does this for NFS and Kerberos, though don't quote me on that
elsewhere. :) Any such system would have a wonderful advantage for the
much faster DAC checks to come first.

Last, the two reasons I have heard for moving the MAC checks first are
thin by my standards: (a) a POSIX draft says to do MAC first (b) running
MAC first prevents the DAC decision variables from being known. I don't
think that we ought to sacrifice speed just for an old POSIX draft. I
also don't think we should be overly concerned with protecting the DAC
decision variables from the user: since the syscall can't return
different error messages based on MAC or DAC error, really only timing
attacks would glean this information; also, it is beginning to smell a
lot like an attempted defense against covert channels. Which, while an
honorable thing to do, starting with Linux may not be the right approach
for any application that truly requires keeping covert channels such as
DAC data closed.

Have I missed any points in favor of moving MAC before DAC? Have I
missed any points in favor of keeping DAC before MAC?

Cheers

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