openMosix & Security

Security is needed within a cluster environment, up till now one of the biggest warnings that were needed when people planned on using openMosix was that their systems security would drop , specially when using oMFS. A node with oMFS enabled actually shared it's whole file system for another oMFS client with zero to no authentication for both reading and writing. oMFS has been removed from the openMosix sources since but other security is being added to a cluster, no authorization or authentication mechanism exists here either.

When we have a look at how nodes are being added to the cluster, we see that there basically is no authentication / authorization at all , if you have the same kernel version as the other nodes in your environment you will join the cluster hence processes will be migrated to you and in the old days you could see the file systems of every other oMFS enabled node in the cluster with no authentication whatsoever.

As process migration happens over the network , and in some cases large, non isolated networks, traffic might be intercepted and analyzed by possible intruders.

One might argue that a cluster needs to be in an isolated environment firewalled from other parts of an organizations network. This is indeed the better way if you are looking for a secure environment. However lots of organizations have lots of idle CPU cycles at night or during the weekends that could be used by their applications. (The 5-9 Clusters as we call them) They didn't do so because rolling out such an environment caused their internal security to be more vulnerable (especially schools/universities etc.. ) with extra security in the clustering platform. This solution becomes a viable alternative again for them ; the speed penalty they have to pay for adding that security doesn't add up to the extra CPU cycles that they can get and that would have been wasted otherwise.

We currently have different alternatives for these issues. The first and most recently contributed one is Evan Turner's openMosix Migration Encryption patch. He developed a patch that will enable encryption on all the data and information that migrates between openMosix nodes specifically ports 0x3214 and 0x3415.

With this patch only the information that is migrated is encrypted, not the entire network. It is considerably faster than using a VPN but it doesn't solve all the problems we discussed above.

Another alternative is the use of the Chaos distribution. This distro, conceived by Ian Latter , aims not only at being a Linux and openMosix distribution that fits on a business card. Chaos does not touch the installed operating systems on the disk so one can use it in a "dual boot" environment. Chaos makes sure that every node in the cluster does its own firewalling and establishes IPSEC tunnels to communicate with other nodes, and this in an extremely transparent way to the to the end user.

Next to adding encryption to the communication it adds a technique for authentication to a new auto-discovery service called tyd which aims at tackling the security issues in omdiscd. Rather than using multicast they use unicast to connect to each node in the cluster, they created a protocol for this called "Terrence and Philip" where Terrence is a client and Philip a server. Each time a client starts (as Terrence) it connects to a Philip and gets the openMosix map from it, it then connects to each node in the cluster and asks to be added. As soon as it is added to all nodes it becomes a server itself. Next to tyd, Chaos also adds IPSec to openMosix tyd hence enabled network level authentication and encryption in a couple of simple steps.