1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="CREATED" content="20010611;10370600">
<meta name="CHANGEDBY" content="Andre Alefeld">
<meta name="CHANGED" content="20010611;11590200">
<title>SGE Security</title>
</head>
<body>
<h2>
SECURITY</h2>
<p><strong>This information is partly historical and describes some
facilities that were never working properly. Currently the only fully
useful security method is <a href="sec/csp.html">CSP</a></strong>, and
it should normally be used, as the system is highly insecure otherwise.
The GSS method is partly functional and the hooks for it could be used
for checking authentication tokens generated by systems other than GSS
ones.</p>
<p><em>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, and
anyone who can access the qmaster on a submission host can impersonate
any other user on execution hosts on which the other user is allowed
to run jobs.</em>
<p>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:</p>
<dl>
<dt>
master host</dt>
<dd>This runs the Grid Engine master daemon sge_qmaster.
<dt>
execution hosts</dt>
<dd>These run the Grid Engine execution daemons sge_execd.
These nodes are allowed to execute Grid Engine jobs.
<dt>
administrative hosts</dt>
<dd>Administrative tasks like the granting of permissions
and the maintenance of resources are only allowed from these hosts.
<dt>
submit hosts</dt>
<dd>Submit hosts allow for submitting and controlling
batch jobs.</dl>
<p>
Apart from the host based access restrictions the
users are classified into the categories:</p>
<dl>
<dt>
managers</dt>
<dd>They have full capabilities to manipulate Grid
Engine.</dd>
<dt>
operators</dt>
<dd>They can perform the same commands as managers
apart from adding/deleting/modifying queues.</dd>
<dd>
owners</dd>
<dd>They can suspend/unsuspend or enable/disable
the queues they are registered as owners.</dd>
<dt>users</dt>
<dd>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.</dd></dl>
<p>
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.
<p>To enhance the security standard there exist
currently three approaches (but only the CSP/OpenSSL one works and is
actually secure — see below):
<ul>
<li>
<a href="#Enhanced Security Using Reserved Ports">Grid
Engine using reserved ports</a></li>
<li>
<a href="#Enhanced Security Using Kerberos/DCE Authentication">Grid
Engine version using Kerberos/DCE authentication</a></li>
<li>
<a href="#Enhanced Security Using Kerberos">Grid
Engine version using Kerberos</a></li>
<li>
<a href="#Enhanced Security Using OpenSSL">Grid Engine
version using SSL</a></li>
</ul>
<h3>
<a NAME="Enhanced Security Using Reserved Ports">Enhanced
Security Using Reserved Ports</a></h3>
<p><em>NB. This mechanism is only of historical interest. It is no
longer supported, and the programs are not designed to be
installed setuid.</em></p>
<p>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.
<br>To make use of this security mechanism the following
steps are necessary:
<ul>
<li>
the shared Grid Engine installation directory must
be exported setuid root</li>
<li>
the installation is performed as root with './install_qmaster
-resport' for qmaster and './install_execd -resport' for execd.
<br>The client binaries are installed setuid root
to be able to connect to Grid Engine from reserved ports.
<li>
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.</li></ul>
<p>What can you expect ?
<p>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.
<br>This implies that the following criteria must
be valid:
<ul>
<li>
there is no possibility to replace a host in the
network by another machine e.g. a Linux laptop where the intruder can install
their own version of Grid Engine binaries and setuid
root them.
<li>
the Grid Engine executables/libraries should not
be replaceable by someone else than root (this must be checked during installation)</li>
<li>
all hosts where root access can be gained are trusted</li>
</ul>
<p>Here are the steps that are performed by a Grid Engine
command as qsub using reserved ports:
<ul>
<li>
qsub is started as setuid root program</li>
<li>
qsub changes its effective user id to the users id
after starting</li>
<li>
client specific processing is executed and a message
for qmaster is prepared</li>
<li>
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</li>
<li>
send the message to qmaster using the file descriptor
in the priviledged port space</li>
<li>
qmaster receives the message, if it has not been
send from the priviledged port space it will be rejected</li>
<li>
check the standard Grid Engine host and user permissions
and allow or reject the request</li>
<li>
qmaster processes the request and sends back any
answers</li>
</ul>
<p>This applies to any other client command.
<h3><a NAME="Enhanced Security Using Kerberos/DCE Authentication"></a>Enhanced
Security Using Kerberos/DCE Authentication</h3>
<p>This GSS-API Kerberos implementation was used regularly in Grid Engine 5.3
development and test environments and is used full-time at at least one production
site which is running Grid Engine 5.3. This
implementation is different than the
<cite>Enhanced Security Using Kerberos</cite>
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.
<p>
Note that this isn't used to authenticate qconf admin commands, just
job submission, and there is no mechanism for "babysitting" tickets
needing renewal. It doesn't currently work properly because the hook
mechanism for calling the sub-programs is partially broken. It will
work within its limits if that is fixed but it may need the interface
changing.
<p>
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 GSS-API modules are used by Grid Engine when it is running in GSS-API mode. 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
<a href="gss/doc/gss_customer.html">gridengine/source/security/gss/doc/gss_customer.html</a>.
<p>Before you start digging into this, make sure you know how Kerberos/DCE functions
in general. There are many good sites out there in Netland.
<br>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 <a href="gss/doc/gss.html">here</a>.
<h3><a NAME="Enhanced Security Using Kerberos"></a>Enhanced
Security Using Kerberos</h3>
<p>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.
<p>
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
<cite>Enhanced Security Using Kerberos/DCE Authentication</cite>
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:
<ul>
<li>
<a href="krb/doc/ReleaseNotes.html">Release Notes</a></li>
<li>
<a href="krb/doc/Implementation.html">Implementation</a></li>
</ul>
<h3><a NAME="Enhanced Security Using OpenSSL"></a>Enhanced
Security Using SSL</h3>
<p>A prototype of Grid Engine supporting SSL was
developed in the context of a diploma thesis. The original diploma thesis (in
German) outlining the architecture of this security approach can be found
<a href="sec/doc/diplomarbeit.ps">here.</a>
<p>The Certificate Security Protocol has been reworked and a description
how to deploy this version can be found <a href="sec/csp.html">here</a>.
<center>
<p>Copyright 2001 Sun Microsystems, Inc. All rights reserved.</center>
</body>
</html>
|
