Re: State of Audit Proposal ?

crispinat_private

Seth Arnold wrote:

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

I consider all performance arguments in the MAC/DAC sequence question to be
bogus.  It doesn't matter which way 'round one thinks is faster.  An access
granted must go through both MAC and DAC, so it doesn't matter which order you
do the check.

Fundamentally, performance in this case is attempting to optimize how quickly
you can return "permission denied."  I submit that optimizing this case is
unimportant, so long as it does not open up a huge DoS hole, e.g. a creative
arrangement in which the attacker can cause either the MAC or DAC code to take
20 minutes of CPU-bound time to decide to reject an access.

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

I agree with Seth that trying to manage timing covert channels in Linux is
futile.  I further agree that, because each syscall can only return "denied",
the application can't tell whether it was MAC or DAC that denied access, and so
no information is leaked by the MAC/DAC check sequence.  And finally, I agree
with Seth that I favor our engineering convenience over that old POSIX
never-adopted standard :-)

So, are there other reasons to put MAC first?  Can someone who wants MAC first
wheel them out, so that we can attempt to compare the Bitch mode issue against
these reasons?  Or is "just 'cause POSIX mandates it" really a big deal to some
people?

Thanks,
    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