On Wed, Sep 07, 2005 at 12:57:27AM +0200, Andreas Brosche wrote: > >The DLM runs over IP, as does the cluster manager. Additionally, please > >remember that GFS requires fencing, and that most fence-devices are > >IP-enabled. > > Hmm. The whole setup is supposed to physically divide two networks, and > nevertheless provide some kind of shared storage for moving data from > one network to another. Establishing an ethernet link between the two > servers would sort of disrupt the whole concept, which is to prevent > *any* network access from outside into the secure part of the network. > This is the (strongly simplified) topology: > > mid-secure network -- Server1 -- Storage -- Server2 -- secure Network > > A potential attacker could use a possible security flaw in the dlm > service (which is bound to the network interface) to gain access to the > server on the "secure" side *instantly* when he was able to compromise > the server on the mid-secure side (hey, it CAN happen). If any sort of > shared storage can be installed *without* any ethernet link or - ideally > - any sort of inter-server communication, there is a way to *prove* that > an attacker cannot establish any kind of connection into the secure net > (some risks remain, but they have nothing to do with the physical > connection). If you are paranoid like that and consider that even if you could do away with dlm and IP connectivity, then o an attacker on the mid-secure network could alter files that the secure network accesses and gain privileges that way. o an attacker can exploit potential bugs in GFS's code, just as well as in dlm's, and having physical access to the Server 2's journals is probably more harmful than trying to hack through dlm's API calls. There is no way to "prove" what you want. Just go for second best to the ideal theorem. You probably don't want GFS, but a hardened NFS connection to the storage allocated within the secure network only. -- Axel.Thimm at ATrpms.net
Attachment:
pgpyzAKLqBJpY.pgp
Description: PGP signature
-- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
