← Back to branch summary

~ubuntu-branches/ubuntu/utopic/gridengine/utopic

« back to all changes in this revision

Viewing changes to source/security/security.html

  • Committer: Bazaar Package Importer
  • Author(s): Mark Hymers
  • Date: 2008-06-25 22:36:13 UTC
  • Revision ID: james.westby@ubuntu.com-20080625223613-tvd9xlhuoct9kyhm
Tags: upstream-6.2~beta2
Import upstream version 6.2~beta2

Show diffs side-by-side

added added

removed removed

Lines of Context:
source/security/security.html
 
1
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 
2
<html>
 
3
<head>
 
4
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 
5
   <meta http-equiv="CONTENT-TYPE" content="text/html; charset=iso-8859-1">
 
6
   <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
 
7
   <meta name="CREATED" content="20010611;10370600">
 
8
   <meta name="CHANGEDBY" content="Andre Alefeld">
 
9
   <meta name="CHANGED" content="20010611;11590200">
 
10
</head>
 
11
<body>
 
12
 
 
13
<h2>
 
14
<b><font color="#990000">SECURITY</font></b></h2>
 
15
<font color="#000000">In default mode Grid Engine is installed without
 
16
any additional security measures.&nbsp; The assumption is made that the
 
17
Grid Engine cluster is not exposed to any malicious attacks.</font>
 
18
<br><font color="#000000">The hosts that belong to the Grid Engine cluster
 
19
are classified into four categories, where a host can belong to more than
 
20
one of them:</font>
 
21
<ul>
 
22
<li>
 
23
<font color="#000000">master host</font></li>
 
24
 
 
25
<br><font color="#000000">Here run the Grid Engine master daemon sge_qmaster
 
26
and the scheduler sge_schedd.</font>
 
27
<li>
 
28
<font color="#000000">execution hosts</font></li>
 
29
 
 
30
<br><font color="#000000">Here run the Grid Engine execution daemons sge_execd.
 
31
These nodes are allowed to execute Grid Engine jobs.</font>
 
32
<li>
 
33
<font color="#000000">administrative hosts</font></li>
 
34
 
 
35
<br><font color="#000000">Administrative tasks like the granting of permissions
 
36
and the maintenance of resources are only allowed from these hosts.</font>
 
37
<li>
 
38
<font color="#000000">submit hosts</font></li>
 
39
 
 
40
<br><font color="#000000">Submit hosts allow for submitting and controlling
 
41
batch jobs.</font></ul>
 
42
<font color="#000000">Apart from the host based access restrictions the
 
43
users are classified into the categories:</font>
 
44
<ul>
 
45
<li>
 
46
<font color="#000000">managers</font></li>
 
47
 
 
48
<br><font color="#000000">They have full capabilities to manipulate Grid
 
49
Engine.</font>
 
50
<li>
 
51
<font color="#000000">operators</font></li>
 
52
 
 
53
<br><font color="#000000">They can perform the same commands as managers
 
54
apart from adding/deleting/modifying queues.</font>
 
55
<li>
 
56
<font color="#000000">owners</font></li>
 
57
 
 
58
<br><font color="#000000">They can suspend/unsuspend or enable/disable
 
59
the queues they are registered as owners.</font>
 
60
<li>
 
61
<font color="#000000">users</font></li>
 
62
 
 
63
<br><font color="#000000">They must have a valid login on at least one
 
64
submit and one execution host. Their access can be limited to a subset
 
65
of them by installing access lists.</font></ul>
 
66
<font color="#000000">These mechanisms rely on the assumption that the
 
67
user is who he claims to be and the host is the host that it claims to
 
68
be and that this information can be trusted.</font>
 
69
<br><font color="#000000">To enhance the security standard there exist
 
70
currently three approaches:</font>
 
71
<ul>
 
72
<li>
 
73
<font color="#000000"><a href="#Enhanced Security Using Reserved Ports">Grid
 
74
Engine using reserved ports</a></font></li>
 
75
 
 
76
<li>
 
77
<font color="#000000"><a href="#Enhanced Security Using Kerberos/DCE Authentication">Grid
 
78
Engine version using Kerberos/DCE authentication</a></font></li>
 
79
 
 
80
<li>
 
81
<font color="#000000"><a href="#Enhanced Security Using Kerberos">Grid
 
82
Engine version using Kerberos</a></font></li>
 
83
 
 
84
<li>
 
85
<font color="#000000"><a href="#Enhanced Security Using OpenSSL">Grid Engine
 
86
version using SSL&nbsp; (work in progress)</a></font></li>
 
87
</ul>
 
88
<a NAME="Enhanced Security Using Reserved Ports"></a><font color="#990000">Enhanced
 
89
Security Using Reserved Ports</font>
 
90
<p><font color="#000000">The simplest security mechanism is the communication
 
91
between Grid Engine components over reserved ports. So any client who is
 
92
not communicating</font>
 
93
<br><font color="#000000">from a priviledged port number is rejected. The
 
94
mechanism used is very similar to the authentication mechanism known from
 
95
the rsh/rlogin command suite.</font>
 
96
<br><font color="#000000">To make use of this security mechanism the following
 
97
steps are necessary:</font>
 
98
<ul>
 
99
<li>
 
100
<font color="#000000">the shared Grid Engine installation directory must
 
101
be exported setuid root</font></li>
 
102
</ul>
 
103
 
 
104
<ul>
 
105
<li>
 
106
<font color="#000000">the installation is performed as root with './install_qmaster
 
107
-resport' for qmaster and './install_execd -resport' for execd</font></li>
 
108
 
 
109
<br><font color="#000000">The client binaries are installed setuid root
 
110
to be able to connect to Grid Engine from reserved ports.</font>
 
111
<br>&nbsp;
 
112
<li>
 
113
<font color="#000000">if you are setting up a system with shared libraries,
 
114
the libraries must be copied to a 'safe' place. The dynamic loader requires
 
115
in general that</font></li>
 
116
 
 
117
<br><font color="#000000">the libraries are installed under /usr/lib or
 
118
some other trusted system path.</font></ul>
 
119
<font color="#000000">What can you expect ?</font>
 
120
<p><font color="#000000">The communication over reserved ports assures
 
121
that only messages that are send from a port in the range 0-1023 are accepted.
 
122
This means that only</font>
 
123
<br><font color="#000000">a program that has been setuid root can send
 
124
such messages. So it can be assured that the client programs you are using
 
125
are the ones that have been</font>
 
126
<br><font color="#000000">installed by the Grid Engine administrator.</font>
 
127
<br><font color="#000000">This implies that the following criteria must
 
128
be valid:</font>
 
129
<ul>
 
130
<li>
 
131
<font color="#000000">there is no possibility to replace a host in the
 
132
network by another machine e.g. a Linux laptop where the intruder can install
 
133
its</font></li>
 
134
 
 
135
<br><font color="#000000">own version of Grid Engine binaries and setuid
 
136
root them.</font>
 
137
<li>
 
138
<font color="#000000">the Grid Engine executables/libraries should not
 
139
be replaceable by someone else than root (this must be checked during installation)</font></li>
 
140
 
 
141
<li>
 
142
<font color="#000000">all hosts where root access can be gained are trusted</font></li>
 
143
</ul>
 
144
<font color="#000000">Here are the steps that are performed by a Grid Engine
 
145
command as qsub using reserved ports:</font>
 
146
<ul>
 
147
<li>
 
148
<font color="#000000">qsub is started as setuid root program</font></li>
 
149
 
 
150
<li>
 
151
<font color="#000000">qsub changes its effective user id to the users id
 
152
after starting</font></li>
 
153
 
 
154
<li>
 
155
<font color="#000000">client specific processing is executed and a message
 
156
for qmaster is prepared</font></li>
 
157
 
 
158
<li>
 
159
<font color="#000000">change the effective user id to root and get a socket
 
160
file descriptor in the priviledged port space, change back to the user's
 
161
id</font></li>
 
162
 
 
163
<li>
 
164
<font color="#000000">send the message to qmaster using the file descriptor
 
165
in the priviledged port space</font></li>
 
166
 
 
167
<li>
 
168
<font color="#000000">qmaster receives the message, if it has not been
 
169
send from the priviledged port space it will be rejected</font></li>
 
170
 
 
171
<li>
 
172
<font color="#000000">check the standard Grid Engine host and user permissions
 
173
and allow or reject the request</font></li>
 
174
 
 
175
<li>
 
176
<font color="#000000">qmaster processes the request and sends back any
 
177
answers</font></li>
 
178
</ul>
 
179
<font color="#000000">This applies to any other client command.</font>
 
180
<p><a NAME="Enhanced Security Using Kerberos/DCE Authentication"></a><font color="#990000">Enhanced
 
181
Security Using Kerberos/DCE Authentication</font>
 
182
<p>This GSS-API Kerberos implementation has used regularly in Grid Engine 5.3
 
183
development and test environments and is used full-time at least one production
 
184
site which is running Grid Engine 5.3.  This
 
185
implementation is different than the
 
186
<font color="#990000">Enhanced Security Using Kerberos</font>
 
187
implementation described below in that it is not a full Kerberos implementation
 
188
but uses Kerberos to authenticate users submitting jobs and to forward user
 
189
credentials with the job by calling security sub-programs at the appropriate times.
 
190
This implementation does not require recompiling Grid Engine.  It consists of security
 
191
modules which can be compiled separately and are called by Grid Engine to do
 
192
authentication and to forward the Kerberos credentials.  The security sub-modules
 
193
are called by client commands (e.g. qsub) and by the Grid Engine daemons
 
194
(sge_qmaster, sge_execd) at the appropriate times to get and store credentials.
 
195
The Kerberos modules are used by Grid Engine when it is running in Kerberos mode
 
196
(i.e. For GE 5.3, the $SGE_ROOT/default/common/product_mode file contains the
 
197
string "sgeee-kerberos" or "sge-kerberos").  The source code for this implementation
 
198
is located in the directory gridengine/source/security/gss.  The source code is
 
199
not dependent on other Grid Engine components or libraries and can be compiled
 
200
stand-alone.  Details on how to use this implementation can be found in
 
201
gridengine/source/security/gss/doc/gss_customer.html.
 
202
<p>Before you start digging into this, make sure how Kerberos/DCE functions
 
203
in general. There are many good sites out there in Netland.
 
204
<br><font color="#000000">Grid Engine can be run in a Kerberos/DCE environment
 
205
using the corresponding authentication mechanisms. A detailed description
 
206
how to integrate Grid Engine in such an enviroment can be found <a href="gss/doc/gss.html">here</a>.</font>
 
207
 
 
208
<p><a NAME="Enhanced Security Using Kerberos"></a><font color="#990000">Enhanced
 
209
Security Using Kerberos</font>
 
210
 
 
211
<p>This implementation isn't really usable in its current form. This code was
 
212
developed around 1997
 
213
for a Raytheon customer which required Kerberos security at their site. This was a
 
214
full Kerberos implementation which used the Kerberos libraries for all communication
 
215
between the daemons and clients. However, the code was never put into production
 
216
and has not been used at any production sites. It was not fully tested and it has
 
217
not been kept up-to-date with the many changes that have been put into Grid Engine
 
218
since that time. The Kerberos support compiled into Grid Engine should be considered
 
219
experimental.  There were several reasons for not finishing this implementation
 
220
(e.g. time and money), but the main reason was the impracticality of supporting
 
221
this version as a product back then (long before Grid Engine was open source)
 
222
because of export restrictions on Kerberos itself and other practical considerations.
 
223
At that time, allowing the customer to compile the code on his own was simply not an
 
224
option, because we didn't supply the source code to customers.
 
225
<p>
 
226
If you need Kerberos to authenticate users who are submitting jobs to allow Grid
 
227
Engine jobs to run with Kerberos credentials (which have been forwarded and are
 
228
protected by encryption), then the 
 
229
<font color="#990000">Enhanced Security Using Kerberos/DCE Authentication</font>
 
230
implementation is the way to
 
231
go.  Full authentication and encrypted communication via Kerberos between all
 
232
Grid Engine clients (e.g. qmon, qstat) and deamons would require using the
 
233
Kerberos code in security/krb, but sure this would involve a significant
 
234
amount of further testing and development. A description of the integration
 
235
and a setup example can be found in the following documents:
 
236
<ul>
 
237
<li>
 
238
<a href="krb/doc/ReleaseNotes.html">Release Notes</a></li>
 
239
 
 
240
<li>
 
241
<a href="krb/doc/Implementation.html">Implementation</a></li>
 
242
</ul>
 
243
 
 
244
<p><a NAME="Enhanced Security Using OpenSSL"></a><font color="#990000">Enhanced
 
245
Security Using SSL</font>
 
246
<p><font color="#000000">A prototype of Grid Engine supporting SSL has
 
247
been developed in the context of a diploma thesis. Although the original
 
248
work is a bit outdated and needs adaption to the newest SSL libraries,
 
249
it is certainly a good starting point. The original diploma thesis (in
 
250
german) outlining the architecture of this security approach can be found
 
251
<a href="sec/doc/diplomarbeit.ps">here.</a>
 
252
<p>The Certificate Security Protocol has been reworked and a description 
 
253
how to deploy this version can be found <a href="sec/csp.html">here</a>
 
254
</font>
 
255
<center>
 
256
<p>Copyright 2001 Sun Microsystems, Inc. All rights reserved.</center>
 
257
 
 
258
</body>
 
259
</html>