SECURITY

In default mode Grid Engine is installed without any additional security measures. The assumption is made that the Grid Engine cluster is not exposed to any malicious attacks.
The hosts that belong to the Grid Engine cluster are classified into four categories, where a host can belong to more than one of them:

master host

Here run the Grid Engine master daemon sge_qmaster and the scheduler sge_schedd.

execution hosts

Here run the Grid Engine execution daemons sge_execd. These nodes are allowed to execute Grid Engine jobs.

administrative hosts

Administrative tasks like the granting of permissions and the maintenance of resources are only allowed from these hosts.

submit hosts

Submit hosts allow for submitting and controlling batch jobs.

Apart from the host based access restrictions the users are classified into the categories:

managers

They have full capabilities to manipulate Grid Engine.

operators

They can perform the same commands as managers apart from adding/deleting/modifying queues.

owners

They can suspend/unsuspend or enable/disable the queues they are registered as owners.

users

They must have a valid login on at least one submit and one execution host. Their access can be limited to a subset of them by installing access lists.

These mechanisms rely on the assumption that the user is who he claims to be and the host is the host that it claims to be and that this information can be trusted.
To enhance the security standard there exist currently three approaches:

Grid Engine using reserved ports
Grid Engine version using Kerberos/DCE authentication
Grid Engine version using Kerberos
Grid Engine version using SSL (work in progress)

Enhanced Security Using Reserved Ports

The simplest security mechanism is the communication between Grid Engine components over reserved ports. So any client who is not communicating
from a priviledged port number is rejected. The mechanism used is very similar to the authentication mechanism known from the rsh/rlogin command suite.
To make use of this security mechanism the following steps are necessary:

the shared Grid Engine installation directory must be exported setuid root

the installation is performed as root with './install_qmaster -resport' for qmaster and './install_execd -resport' for execd

The client binaries are installed setuid root to be able to connect to Grid Engine from reserved ports.

if you are setting up a system with shared libraries, the libraries must be copied to a 'safe' place. The dynamic loader requires in general that

the libraries are installed under /usr/lib or some other trusted system path.

What can you expect ?

The communication over reserved ports assures that only messages that are send from a port in the range 0-1023 are accepted. This means that only
a program that has been setuid root can send such messages. So it can be assured that the client programs you are using are the ones that have been
installed by the Grid Engine administrator.
This implies that the following criteria must be valid:

there is no possibility to replace a host in the network by another machine e.g. a Linux laptop where the intruder can install its

own version of Grid Engine binaries and setuid root them.

the Grid Engine executables/libraries should not be replaceable by someone else than root (this must be checked during installation)
all hosts where root access can be gained are trusted

Here are the steps that are performed by a Grid Engine command as qsub using reserved ports:

qsub is started as setuid root program
qsub changes its effective user id to the users id after starting
client specific processing is executed and a message for qmaster is prepared
change the effective user id to root and get a socket file descriptor in the priviledged port space, change back to the user's id
send the message to qmaster using the file descriptor in the priviledged port space
qmaster receives the message, if it has not been send from the priviledged port space it will be rejected
check the standard Grid Engine host and user permissions and allow or reject the request
qmaster processes the request and sends back any answers

This applies to any other client command.

Enhanced Security Using Kerberos/DCE Authentication

This GSS-API Kerberos implementation has used regularly in Grid Engine 5.3 development and test environments and is used full-time at least one production site which is running Grid Engine 5.3. This implementation is different than the Enhanced Security Using Kerberos implementation described below in that it is not a full Kerberos implementation but uses Kerberos to authenticate users submitting jobs and to forward user credentials with the job by calling security sub-programs at the appropriate times. This implementation does not require recompiling Grid Engine. It consists of security modules which can be compiled separately and are called by Grid Engine to do authentication and to forward the Kerberos credentials. The security sub-modules are called by client commands (e.g. qsub) and by the Grid Engine daemons (sge_qmaster, sge_execd) at the appropriate times to get and store credentials. The Kerberos modules are used by Grid Engine when it is running in Kerberos mode (i.e. For GE 5.3, the $SGE_ROOT/default/common/product_mode file contains the string "sgeee-kerberos" or "sge-kerberos"). The source code for this implementation is located in the directory gridengine/source/security/gss. The source code is not dependent on other Grid Engine components or libraries and can be compiled stand-alone. Details on how to use this implementation can be found in gridengine/source/security/gss/doc/gss_customer.html.

Before you start digging into this, make sure how Kerberos/DCE functions in general. There are many good sites out there in Netland.
Grid Engine can be run in a Kerberos/DCE environment using the corresponding authentication mechanisms. A detailed description how to integrate Grid Engine in such an enviroment can be found here.

Enhanced Security Using Kerberos

This implementation isn't really usable in its current form. This code was developed around 1997 for a Raytheon customer which required Kerberos security at their site. This was a full Kerberos implementation which used the Kerberos libraries for all communication between the daemons and clients. However, the code was never put into production and has not been used at any production sites. It was not fully tested and it has not been kept up-to-date with the many changes that have been put into Grid Engine since that time. The Kerberos support compiled into Grid Engine should be considered experimental. There were several reasons for not finishing this implementation (e.g. time and money), but the main reason was the impracticality of supporting this version as a product back then (long before Grid Engine was open source) because of export restrictions on Kerberos itself and other practical considerations. At that time, allowing the customer to compile the code on his own was simply not an option, because we didn't supply the source code to customers.

If you need Kerberos to authenticate users who are submitting jobs to allow Grid Engine jobs to run with Kerberos credentials (which have been forwarded and are protected by encryption), then the Enhanced Security Using Kerberos/DCE Authentication implementation is the way to go. Full authentication and encrypted communication via Kerberos between all Grid Engine clients (e.g. qmon, qstat) and deamons would require using the Kerberos code in security/krb, but sure this would involve a significant amount of further testing and development. A description of the integration and a setup example can be found in the following documents:

Enhanced Security Using SSL

A prototype of Grid Engine supporting SSL has been developed in the context of a diploma thesis. Although the original work is a bit outdated and needs adaption to the newest SSL libraries, it is certainly a good starting point. The original diploma thesis (in german) outlining the architecture of this security approach can be found here.

The Certificate Security Protocol has been reworked and a description how to deploy this version can be found here