Re: State of Audit Proposal ?

From: Crispin Cowan (crispinat_private)
Date: Fri Jul 20 2001 - 16:59:44 PDT

  • Next message: James Morris: "Re: Patch: Socket hooks"

    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
    



    This archive was generated by hypermail 2b30 : Fri Jul 20 2001 - 17:01:35 PDT