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:
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
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
The Grid Engine has been prepared for usage in a Kerberos V environment.
A former version of Grid Engine (aka Codine/GRD) is in use in a production
environment with Kerberos support. Although several source code changes
have been applied to the current version, it should be easy to integrate
Grid Engine into a Kerberos V environment. 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
Copyright 2001 Sun Microsystems, Inc. All rights reserved.