Re: A Comment from User Space

From: Crispin Cowan (crispinat_private)
Date: Tue Apr 24 2001 - 00:27:58 PDT

  • Next message: jmjonesat_private: "Re: A Comment from User Space"

    Valdis.Kletnieksat_private wrote:
    
    > BUT WHAT IF IT ACTUALLY WORKED?
    >
    > How many security-critical apps would use it instead of jumping
    > through the current contortions they go through to check?
    
    I submit that the number is "very nearly zero."  At the moment, anyway, I'm more
    convinced by the arguments that a well-constructed app. just does what it is supposed
    to do, and doesn't try to probe to see what is permitted.
    
    
    > How many apps that jump through those hoops get it *wrong*?
    
    I give up:  how many?  What are some legitimate examples? The current uses of
    access() that I'm familiar with are:
    
       * Bad temp file creation:  subject to TOCTTOU errors.  Use mkstemp instead.
       * Installation probes checking to see if files & directories exist & with what
         permissions before attempting to create them.  Often these installation probes
         get this wrong, too, and are subject to TOCTTOU errors.
    
    > > You'd have to invent a new, secure interface to get this right, and access()
    > > isn't it.  Haven't I explained this about five or six times now?
    >
    > Right. And I'm saying that *THIS* is the time to at least think about
    > defining a new, secure interface.
    
    With all due respect, no it isn't.  More precisely, this is not the forum for
    debating the merrits of funky new security models.  This is the forum for finding
    unifying abstractions and implementations for support hooks to allow existing
    security models to operate on the Linux kernel.
    
    Inventing new security models is a fine thing to do, and I encourage you to do it.
    Just don't do it here.  Go mature your idea somewhere else, and come back with a
    working kernel patch, some experimentation that shows that your way has some value,
    and a request list of hooks that you need, but LSM does not provide.
    
    In the mean time, it's hard enough to find common ground between the diverse existing
    models without trying to generalize to support a hypothetical security facility that
    does not exist, and has murkey security value.  Only when there is working code for a
    proposed new security extension can we consider whether the LSM interface provides
    for that code.
    
    Crispin
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    
    
    _______________________________________________
    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 : Tue Apr 24 2001 - 00:29:58 PDT