Re: Dump a mode --x--x--x binary on Linux 2.0.x

From: Neale Banks (nealeat_private)
Date: Wed Sep 16 1998 - 14:24:57 PDT

  • Next message: Charles M. Hannum: "FreeBSD VM gremlin"

    On Wed, 16 Sep 1998, David Luyer wrote:
    [...]
    > The fact some programs install mode 111 means that it is expected to protect
    > the binary.
    >
    > The fact that you can't core dump or directly read a mode 111 binary means that
    > there is an expectation of security.
    [...]
    > Being able to override the expectations of those programs which are installed
    > mode 111 _is_ a security problem in that it violates expected semantics and
    > that when a given Unix variant makes any attempt to enforce these semantics
    > it should make sure it completely enforces them, instead of giving a false
    > sense of security.  Sound like "security by obscurity" to anyone?
    
    As has already been raised, NFS doesn't distinguish between read-for-exec
    and read-for-read (and I think this can be generalised to "can't
    distinguish" for _all_ file-system exporting protocols, as any enforcement
    would have to be in the client :-0 ).
    
    As previously suggested, surely this relegates the matter from mainstream
    bug to secure-linux patch?  In this case you would have to at least patch
    against:
    
    (a) inadvertent dumping of mode 111 files
    (b) exporting mode 111 files (effectively export them as mode 000)
    (c) be sure to properly handle mode 111 directories too
    (d) no doubt, a string of other possibilities.
    
    What have we "broken" so far?
    
    In short, it does not appear reliable to rely on mode 111 as providing any
    _substantial_ confidentiality, except in a specifically secured
    environment.  This then assumes that the person requiring the
    confidentiallity also has control of the secured environment.
    
    Perhaps David and I are "furiously agreeing"?
    
    Regards,
    Neale.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:16:34 PDT