Bugtraq mailing list archives
Re: Read only devices (Re: BoS: amodload.tar.gz - ...)
From: mdz () NETRAIL NET (Matt Zimmerman)
Date: Fri, 21 Jun 1996 13:59:49 -0400
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]
Current thread:
- Read only devices (Re: BoS: amodload.tar.gz - ...) William McVey (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Patrick Ferguson (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Sean Vickery (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Matt Zimmerman (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Sean Vickery (Jun 20)
- <Possible follow-ups>
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Scott J. Kramer (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Brian Tao (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Don Lewis (Jun 20)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Matt Zimmerman (Jun 21)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Christopher Samuel (Jun 21)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Chris A. Petro (Jun 22)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) R.Arnold / Arny (Jun 24)
- Re: Read only devices (Re: BoS: amodload.tar.gz - ...) Patrick Ferguson (Jun 20)