Overview	Applications	Security	Performance	Simplicity	Cost Effective	Easy Access

Security

Security is paramount importance if you're looking to reap the advantages of volunteer grid computing. If you can use other people's computers when they aren't - without exposing those systems to risk - you stand to gain a tremendous amount of computing power.

But how do you avoid putting those computers at risk?

The development of JIVA was motivated by questions like "What's the worst thing that could happen if someone wrote a virus for volunteer grid systems?" JIVA is also motivated by the answer to this question: If you deploy a virus on your cluster, you lose your cluster. If you deploy a virus on your IT infrastructure, you can lose your business.

JIVA is designed to make it easy to deploy new applications to the JIVA Clients: they will connect to whatever JIVA Server you configure them to and they will download and run whatever application the JIVA Server provides. Left unchecked, this would be an excellent way to deploy a virus that could delete important data, pass credit card information to identity thieves, send "Sasser" class worms to every person in the user's email address book, or simply operate as an open email relay for spammers.

So, what are the options for making sure that the code your Grid client runs is safe? For starters, you can make sure that the Grid client only runs code signed by trusted organizations. What people think this does is make your computer safe. What it actually does is dramatically reduce the odds of your computer accidentally running malware (trojan horse viruses, worms, etc.).

The downside to blind faith in trusted code is that accidents happen. Look at the security holes in Microsoft Windows. Consider how much business revenue has been lost in the United States due to these security problems. Consider how hard it is to keep a straight face when your browser presents you with a code-signing certificate and offers you the option to "Always trust software from Microsoft."

If a company you trust (perhaps your own company) downloads library binaries to use for development and doesn't do an md5 check on the libraries before linking them in with their code, they are opening the door for trojan horse viruses. If they link the libraries with their own code, and then sign the entire package, you now have signed code from a trusted source that contains a virus.

Likewise, there are simply bugs. Suppose that a program does some work, stores intermediate results in a scratch directory and then deletes the directory when completed. Improper input (like a null string) could cause the directory to delete a user directory instead of a subdirectory inside the user's folder. This bug could easily be present in a signed code library.

All that signing code does is tell you who to blame when it's already too late.

The Solution: Run-time Checking

Java, on the other hand, has the capability to provide run-time checking. If the security manager is enabled, the Java runtime will check every line of code before it is executed. If the code attempts to delete the user's directory (forbidden), the code will be halted. If the code attempts to read from anywhere outside of its own scratch directory, the code will be halted. If the code attempts to open an unauthorized network connection, it will be halted.

Runtime checking provides 11th hour preventative measures against the things the developers didn't know about their code

A summary of JIVA security measures

1. JIVA itself is only allowed read access to its security policy and nobody - including JIVA's creators - can circumvent this.
2. At runtime, the Java Security Manager assures the safety of the problem-solving software by checking every instruction against the rules listened in the security policy before permitting the JVM to execute the instruction. If any instruction violates any of these rules, the Security Manager immediately shuts down the entire JVM to prevent execution of that instruction.
3. Clients only execute code signed by trusted entities.
4. Clients initiate all transactions with server, no open ports for spoofing.
5. All transactions are performed over port 80, so no additional ports need to be opened on firewalls.
6. The client may only open connections to the JIVA Server.
7. The client may not execute any externel applications
8. File access is allowed only within the JIVA scratch directory.
9. Only tasks signed by a trusted source will execute on the Client.