[2779] in bugtraq
Re: Read only devices (Re: BoS: amodload.tar.gz - ...)
daemon@ATHENA.MIT.EDU (Matt Zimmerman)
Fri Jun 21 17:48:50 1996
Date: Fri, 21 Jun 1996 13:59:49 -0400
Reply-To: Matt Zimmerman <mdz@NETRAIL.NET>
From: Matt Zimmerman <mdz@NETRAIL.NET>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199606210538.WAA18304@salsa.gv.ssi1.com>
On Thu, 20 Jun 1996, Don Lewis wrote:
> } Right...which makes a good case for using NFS instead, and exporting the
> } filesystems read-only from a server which is hopefully less accessible to
> } the general public and/or intruders (offering a very limited set of
> } network services, etc.). Of course, then you have to deal with the usual
> } NFS security issues (most of which can be avoided within reasonable limits
> } by well-configured firewalls and TCP wrappers).
> I don't think NFS can be made safe enough. The intruder could inject
> NFS responses onto the network that would substitute his own pieces
> for pieces of the system binaries that you're trying to protect. This
> would be similar to the potential attack against the Netscape browser
> cryptographic machinery that was reported a while back. Even if the
> network is secured and only contains the read-only NFS server and the
> "diskless" client, if the attacker has root privileges on the client
> and is able to gain access to something like NIT or BPF, the attack
> could be carried out from the client machine.
Yes, trojan horse attacks of this sort would still be possible, but
(unless I've lost track of things, which is definitely possible) I believe
the goal was to facilitate a post-compromise cleanup. Besides, what would
be accomplished by such an attack when the intruder already has root?
With an NFS (or a hypothetical security-oriented remote file sharing
system, with encryption and all sorts of other goodies) approach, you
could be sure, within the limits of the security of the NFS server, that
your system binaries were clean. The nature of the NFS server would make
it possible to lock things down quite a bit more than on the public server
(perhaps as far as disallowing network connections altogether, with the
exception of RPC, and making changes locally). This makes backup
comparisons, etc. unnecessary for the read-only parts of the filesystem
during cleanup; a tripwire or similar database could be maintained on the
"secure" server to aid in checking system areas that must be writable.
// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
