[7959] in bugtraq
Re: Dump a mode --x--x--x binary on Linux 2.0.x
daemon@ATHENA.MIT.EDU (Neale Banks)
Thu Sep 17 12:56:52 1998
Date: Thu, 17 Sep 1998 07:24:57 +1000
Reply-To: Neale Banks <neale@LOWENDALE.COM.AU>
From: Neale Banks <neale@LOWENDALE.COM.AU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199809160318.LAA13423@typhaon.ucs.uwa.edu.au>
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.
