Re: State of Audit Proposal ?

From: David Wagner (dawat_private)
Date: Mon Jul 23 2001 - 09:18:51 PDT

  • Next message: Casey Schaufler: "Re: State of Audit Proposal ?"

    KRAMER,STEVEN (HP-USA,ex1) wrote:
    >In the past, I would have agreed that covert channels are a bit
    >esoteric to worry about in real-life OSes.  But given the propensity
    >of crackers to defeat so many existing protection mechanisms, isn't
    >this something we should consider (at least bookmark it for later
    >examination)?
    
    No.  The whole covert channel model---you give some untrusted code access
    to confidential data, and then you try to prevent that code from spilling
    the beans---is fundamentally broken, in my view, because you're doomed
    to failure.  Getting rid of all the covert channels is a Herculean task.
    
    A better model: Just don't give that untrusted code access to the
    confidential data in the first place, and voila!, no more worries about
    covert channels.  Sure, you gotta be really careful about who gets read
    access to the data, but it's likely to be much easier to be careful
    about this than to be careful about covert channels.
    
    In any case, even if you don't buy my argument and still worry about
    covert channels, the most compelling argument is that Linux is unlikely
    to be the right base to build on.  It is extremely hard to retrofit
    legacy systems to reliably remove all covert channels.  If you want to
    build a system that is free of covert channels, starting from Linux is
    likely to lead to a rathole from which this list would never emerge.
    
    That's my take on it, anyway.  But this is a matter of policy, not of
    mechanism, so if some LSM writer can find a way to stop covert channels
    within the existing schema of hooks, more power to them.  My main concern
    would be if someone wants to radically change the direction of LSM just
    to support covert channel elimination: I claim that they would have an
    almost-zero chance of succeeding, and radical changes to the architecture
    without corresponding benefits should be avoided if they put acceptance
    of the LSM kernel patches at risk.
    
    _______________________________________________
    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 : Mon Jul 23 2001 - 09:36:31 PDT