Note
|
The Grid Community Toolkit documentation was taken from the Globus Toolkit 6.0 documentation. As a result, there may be inaccuracies and outdated information. Please report any problems to the Grid Community Forums as GitHub issues. |
GCT → Admin Manuals → GCT 6.2 Installation Appendix
Advanced Installation for GCT 6.2
This section introduces building from Git, and references the advanced installation sections of component documentation.
Advanced Installation
Building from Git
The Grid Community Toolkit is available for download from github. See https://github.com/gridcf/gct to branch or checkout the toolkit source code.
After checking out the toolkit, run autoreconf -i
in the
checkout root to generate configure scripts for building the toolkit
components.
Building a specific package from source
If you need to build a specific package from the source installer, you can use the per-package make targets that exist in the source installer’s Makefile. Instead of simply running "make" in the steps above, you can, for example, run "make globus_common" which will build the globus_common package and its dependencies, or "make globus_common-only" which will build exactly and only the globus_common package. Similar targets exist for each package.
Detailed installation instructions for these components
The following is a list of links to more detailed installation information available for the following components:
Building an update package without an installer
If you need to build an updated package that has been released without a
source installer (for example, a security update to a package, or a new
version of MyProxy,) you can use the familiar configure; make; make
install
sequence to rebuild that package.
Packaging details
The makefile
You do not have to build every subcomponent of this release. The makefile specifies subtargets for different functional subpieces.
-
gram: GRAM5
-
gridftp: GridFTP
Note that all of these targets require the "install" target also. So, for instance, to build GridFTP alone, you would run:
$ ./configure --prefix=/path/to/install $ make gridftp install
Linking with Grid Community Toolkit Libraries
Since GT 2.0, the toolkit has included a script called globus-makefile-header that can be used to assemble the cflags and link line information when linking a program with libraries included in the toolkit. This script would walk the package metadata dependency tree to ensure that all needed flags were included, without duplicates. This method worked, and continues to work in GCT 6.2, but we consider it to be obsolete, as we have added support for using link: pkg-config
Pkg-config is very similar in concept to globus-makefile-header, but it has gained widespread adoption across a range of unix platforms.
To get the cflags and link line information to link to the globus-ftp-client library, for example, you could
$ pkg-config --cflags --libs globus-ftp-client
Each Grid Community Toolkit library has a pkg-config metadata file that is installed as part of its devel package.
For more information about pkg-config, please see the pkg-config homepage.
Environment Variables in GCT 6.2
Common Runtime Environmental Variables
Environmental variables for XIO
The vast majority of the environment variables that affect the Globus XIO framework are defined by the driver in use. The following are links to descriptions of the more common driver environment variables:
Environment variables for C Common Libraries
- GLOBUS_HOSTNAME
-
Set this variable to the fully qualified name of the local machine’s hostname.
- GLOBUS_DOMAIN_NAME
-
Set this variable to the domain name to be used to qualify the local machine’s hostname.
- GLOBUS_ERROR_OUTPUT
-
Set this variable to 1 to cause Globus libraries to display error information to stderr.
- GLOBUS_ERROR_VERBOSE
-
Set this variable to 1 to enable verbose error messages.
- GLOBUS_I18N
-
Set this variable to 1 to attempt to use localized messages. (Currently not working)
- GLOBUS_LOCATION
-
Set this variable to the path where the Grid Community Toolkit is installed, so that GCT tools can find libraries and data files. This is only needed if the Grid Community Toolkit was built with the source installer.
- GLOBUS_THREAD_MODEL
-
Set to the name of a thread model to control the operation of the GCT event driver. Valid values are (depending on the platform)
none
for non-threaded operation (the default),pthread
for POSIX threads, orwindows
for Windows threads.
Security Environmental Variables
Environmental Variables for GSI C
Credentials
Credentials are looked for in the following order:
-
service credential
-
host credential
-
proxy credential
-
user credential
X509_USER_PROXY
specifies the path to the proxy credential. If
X509_USER_PROXY
is not set, the proxy credential is created (by
grid-proxy-init
) and searched for (by client programs) in an
operating-system-dependent local temporary file.
X509_USER_CERT
and X509_USER_KEY
specify the path to the end
entity (user, service, or host) certificate and corresponding private
key. The paths to the certificate and key files are determined as
follows:
For service credentials:
-
If
X509_USER_CERT
andX509_USER_KEY
exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
/etc/grid-security/service/servicecert.pem
and and/etc/grid-security/service/servicekey.pem
exist and contain a valid certificate and key, those files are used. exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
$GLOBUS_LOCATION/etc/grid-security/service/servicecert.pem
and and$GLOBUS_LOCATION/etc/grid-security/service/servicekey.pem
exist and contain a valid certificate and key, those files are used. exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
service/servicecert.pem
and andservice/servicekey.pem
in the user’s in the user’s.globus
directory exist and contain a valid certificate and key, those files are used. directory exist and contain a valid certificate and key, those files are used.
For host credentials:
-
If
X509_USER_CERT
andX509_USER_KEY
exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
/etc/grid-security/hostcert.pem
and and/etc/grid-security/hostkey.pem
exist and contain a valid certificate and key, those files are used. exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
$GLOBUS_LOCATION/etc/hostcert.pem
and and$GLOBUS_LOCATION/etc/hostkey.pem
exist and contain a valid certificate and key, those files are used. exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
hostcert.pem
and andhostkey.pem
in the user’s in the user’s.globus
directory, exist and contain a valid certificate and key, those files are used. directory, exist and contain a valid certificate and key, those files are used.
For user credentials:
-
If
X509_USER_CERT
andX509_USER_KEY
exist and contain a valid certificate and key, those files are used. -
Otherwise, if the files
usercert.pem
and anduserkey.pem
exist in the user’s exist in the user’s.globus
directory, those files are used. directory, those files are used. -
Otherwise, if a PKCS-12 file called
usercred.p12
exists in the user’s exists in the user’s.globus
directory, the certificate and key are read from that file. directory, the certificate and key are read from that file.
Gridmap file
GRIDMAP
specifies the path to the grid map file, which is used to
map distinguished names (found in certificates) to local names (such as
login accounts). The location of the grid map file is determined as
follows:
. If the GRIDMAP
environment variable is set, the grid map file location is the value of that environment variable.
-
Otherwise:
-
If the user is root (uid 0), then the grid map file is
/etc/grid-security/grid-mapfile
.. -
Otherwise, the grid map file is
$HOME/.gridmap
..
-
Trusted CAs directory
X509_CERT_DIR
is used to specify the path to the trusted
certificates directory. This directory contains information about which
CAs are trusted (including the CA certificates themselves) and, in some
cases, configuration information used by grid-cert-request
to
formulate certificate requests. The location of the trusted certificates
directory is determined as follows:
. If the X509_CERT_DIR
environment variable is set, the trusted certificates directory is the value of that environment variable.
-
Otherwise, if
$HOME/.globus/certificates
exists, that directory is the trusted certificates directory. exists, that directory is the trusted certificates directory. -
Otherwise, if
/etc/grid-security/certificates
exists, that directory is the trusted certificates directory. exists, that directory is the trusted certificates directory. -
Finally, if
$GLOBUS_LOCATION/share/certificates
exists, then it is the trusted certificates directory. exists, then it is the trusted certificates directory.
GSI authorization callout configuration file
GSI_AUTHZ_CONF
is used to specify the path to the GSI authorization
callout configuration file. This file is used to configure authorization
callouts used by both the gridmap and the authorization API. The
location of the GSI authorization callout configuration file is
determined as follows:
. If the GSI_AUTHZ_CONF
environment variable is set, the authorization callout configuration file location is the value of this environment variable.
-
Otherwise, if
/etc/grid-security/gsi-authz.conf
exists, then this file is used. exists, then this file is used. -
Otherwise, if
$GLOBUS_LOCATION/etc/gsi-authz.conf
exists, then this file is used. exists, then this file is used. -
Finally, if
$HOME/.gsi-authz.conf
exists, then this file is used. exists, then this file is used.
GAA (Generic Authorization and Access control) configuration file
GSI_GAA_CONF
is used to specify the path to the GSI GAA (Generic
Authorization and Access control)
configuration file. This file
is used to configure policy language specific plugins to the GAA-API.
The location of the GSI GAA configuration file is determined as follows:
. If the GSI_GAA_CONF
environment variable is set, the GAA configuration file location is the value of this environment variable.
-
Otherwise, if
/etc/grid-security/gsi-gaa.conf
exists, then this file is used. exists, then this file is used. -
Otherwise, if
$GLOBUS_LOCATION/etc/gsi-gaa.conf
exists, then this file is used. exists, then this file is used. -
Finally, if
$HOME/.gsi-gaa.conf
exists, then this file is used. exists, then this file is used.
Grid security directory
GRID_SECURITY_DIR
specifies a path to a directory containing
configuration files that specify default values to be placed in
certificate requests. This environment variable is used only by the
grid-cert-request
and grid-default-ca
commands.
The location of the grid security directory is determined as follows:
. If the GRID_SECURITY_DIR
environment variable is set, the grid security directory is the value of that environment variable.
-
If the configuration files exist in
/etc/grid-security
, the grid security directory is that directory., the grid security directory is that directory. -
if the configuration files exist in
$GLOBUS_LOCATION/etc
, the grid security directory is that directory., the grid security directory is that directory.
Using TLS
GLOBUS_GSSAPI_FORCE_TLS
specifies whether to use TLS by default when
establishing a security context. The default behavior if this is not set
is to use SSLv3.
Name Comparisons
GLOBUS_GSSAPI_NAME_COMPATIBILITY
specifies what name matching
algorithms are supported by GSSAPI for mutual authentication and
gss_compare_name
. This variable may be set to any of the
following values:
STRICT_GT2
-
Strictly backward-compatible with GT 2.0 name matching. X.509 subjectAltName values are ignored. Names with hyphens are treated as wildcarded as described in the security considerations documentation. Name matching will rely on canonical host name associated with connection IP addresses.
STRICT_RFC2818
-
Support RFC 2818 server identity processing. Hyphen characters are treated as normal part of a host name. DNSName and IPAddress subjectAltName extensions are matched against the host and port passed to GSSAPI. If subjectAltName is present, X.509 SubjectName is ignored.
HYBRID
: Support a hybrid of the two previous name matching algorithms, liberally matching both hyphen wildcards, canonical names associated with IP addresses, and subjectAltName extensions.
If this variable is not set, the HYBRID
behavior is used.
Environmental variables for MyProxy
Please refer to the MyProxy Reference Manual for documentation of MyProxy environment variable interfaces.
Environmental variables for GSI-OpenSSH
The GSI-enabled OpenSSHD needs to be able to find certain files and directories in order to properly function.
The items that OpenSSHD needs to be able to locate, their default location and the environment variable to override the default location are:
-
Host key
-
Host certificate
-
Grid map file
-
Certificate directory
Data Management Environmental Variables
Environment variables for GridFTP
The GridFTP server or client libraries do not read any environment variable directly, but the security and networking related variables described below may be useful.
Installing SimpleCA
Building and Installing
Create users
Make sure you have the following users on your machine:
-
Your user account, which will be used to run the client programs.
-
A
simpleca
account, which will be used to administer the Simple CA. This is created automatically if you install SimpleCA from RPM or Debian packages. -
A generic
globus
account, if you will be building from the source installer.
Install SimpleCA
SimpleCA can be installed in three ways, from a debian package, from an RPM package, and from the source installer. These installation methods are described in Installing GCT 6.2.
To install SimpleCA from binary packages, install the packages
globus-simple-ca
and globus-gsi-cert-utils-progs
and
their dependencies. On Debian based systems, use the command
root# apt-get install
On RPM-based systems, use the command
root# yum install
To install SimpleCA from the source installer, build the
globus_simple_ca
and globus_gsi_cert_utils
installer targets
with the command
globus% make
Afterward, run the command
globus% make install
Creating a SimpleCA
If you install the globus-simpleca Debian or RPM package, it will
automatically create a simpleca
user and a Simple CA in
/var/lib/globus/simple_ca
. If want to create a custom CA, or are
using the source installer, you’ll need to do the following. Otherwise,
you can skip to the . If want to create a custom CA, or are using the
source installer, you’ll need to do the following. Otherwise, you can
skip to the Using a SimpleCA
chapter of the SimpleCA documentation, as these steps have already been
done.
Create SimpleCA Administrator Account
Create a user to adminster the SimpleCA. You can use the the
globus
user you used to build GCT, or another user that you
create. For the purposes of this document, we’ll assume a user named
simpleca
. Log in to that user, and run the
grid-ca-create
command. This will prompt for information needed
to name the certificate, how to contact the CA administrator, lifetime
of the CA certificate, and passphrase, and will then generate the new CA
certificate and private key. Command-line options described in
grid-ca-create
can
be used to avoid some of these prompts.
Invoking grid-ca-create
If you are creating a SimpleCA for testing purposes, you can use the
-noint command-line option to grid-ca-create
to use the
default values for all prompts like this:
simpleca% grid-ca-create -noint
This will create a SimpleCA in the simpleca
's home directory
with the passphrase globus
. You can then move on to the
Using a SimpleCA chapter of
this document. For step-by-step details to create a customized SimpleCA,
continue reading this chapter.
As the simpleca
user, run the command grid-ca-create
,
and you’ll see output like this:
simpleca% grid-ca-create C e r t i f i c a t e A u t h o r i t y S e t u p This script will setup a Certificate Authority for signing Globus users certificates. It will also generate a simple CA package that can be distributed to the users of the CA. The CA information about the certificates it distributes will be kept in: /home/simpleca/.globus/simpleCA
This intro screen shows the path that the CA will be created into (in
this example, /home/simpleca/.globus/simpleCA
). The other commands
needed by SimpleCA will automatically look in that path by default when
invoked by the ). The other commands needed by SimpleCA will
automatically look in that path by default when invoked by the
simpleca
user.
Configure the subject name
The grid-ca-create
program next prompts you for information
about the name of CA you wish to create:
The unique subject name for this CA is: cn=Globus Simple CA, ou=simpleCA-elephant.globus.org, ou=GlobusTest, o=Grid Do you want to keep this as the CA subject (y/n) [y]:
To accept the default name, enter y
. To choose a different name,
type n
, after which you will be prompted by
Enter a unique subject name for this CA:
The subject name is an X.509 distinguished name. Typical name component type abbreviations used in Grids are:
- cn
-
Represents "common name". It identifies this particular certificate as the CA Certificate within the "GlobusTest/simpleCA-elephant.globus.org" domain, which in this case is Globus Simple CA.
- ou
-
Represents "organizational unit". It identifies this CA from other CAs created by SimpleCA by other people. The second "ou" is specific to your hostname (in this case GlobusTest).
- o
-
Represents "organization". It identifies the Grid.
Configure the CA’s email
The next prompt looks like this:
Enter the email of the CA (this is the email where certificate requests will be sent to be signed by the CA) [[email protected]]:
Enter the email address where you intend to receive certificate
requests. It should be your real email address that you check, not the
address of the globus user. When users request certificates with
grid-cert-request
, they will be instructed to send the request
to this address.
Configure the expiration date
Then you’ll see:
The CA certificate has an expiration date. Keep in mind that once the CA certificate has expired, all the certificates signed by that CA become invalid. A CA should regenerate the CA certificate and start re-issuing ca-setup packages before the actual CA certificate expires. This can be done by re-running this setup script. Enter the number of DAYS the CA certificate should last before it expires. [default: 5 years 1825 days]:
This is the number of days for which the CA certificate is valid. Once this time expires, the CA certificate will have to be recreated.
To accept the default, hit enter
, or otherwise, enter a value in
days.
Create a Passphrase to Encrypt the CA’s Private Key
The next prompt will be for the passphrase for the CA’s private key. It will be used to decrypt the CA’s private key when signing certificates. It should be hard to guess, as its compromise might compromise all the certificates signed by the CA. You will be prompted twice for the passphrase, to verify that you typed it correctly. Enter the passphrase at these prompts.
Enter PEM pass phrase: Verifying - Enter PEM pass phrase:
SimpleCA Distribution Files
Finally grid-ca-create
will create a tarball containing the
public information about the CA, including its public certificate,
signing policy, and supported X.509v3 extensions. This information is
needed on machines that will be trusting the CA, and also on machines
which will be used to request certificates from this CA.
Since we didn’t run in this example as root, grid-ca-create
will
not be able to write the CA files to system paths, so it displays a
warning message indicating that. We can use the tarball output here, or
packages described below to install the CA support files on this and
other machines.
The package output summary looks like this:
Insufficient permissions to install CA into the trusted certifiicate directory (tried ${sysconfdir}/grid-security/certificates and ${datadir}/certificates) Creating RPM source tarball... done globus_simple_ca_68ea3306
This information will be important for setting up other machines in your grid. The number 68ea3306 in the last line is known as your CA hash. It is an 8 digit hexadecimal string which is a hash of the subject name of the CA certificate.
The tarball contains Debian and RPM package metadata, so that it can be compiled to a binary package which can be easily installed on this and other systems on your Grid. It can also be packaged as a GPT setup package for compatibility with older versions of the Globus Toolkit.
Generating Binary CA Packages
The
grid-ca-package
command can be used to generate RPM, debian, or legacy GPT packages for a
SimpleCA, or for any other CA which is installed on a host. These packages can
make it easy to distribute the CA certificate and policy to other hosts
with which you want to establish Grid trust relationships.
Generating RPM Packages
To generate an RPM package for the CA which we created, use the following command:
simpleca% grid-ca-package -r -cadir ~/.globus/simpleCA Creating RPM source tarball... done globus_simple_ca_68ea3306.tar.gz Creating RPM binary.../home/simpleca/globus-simple-ca-68ea3306
The resulting rpm package will be placed in the current directory. As
root, you can install this via the yum
or rpm
tools.
This package can then be installed on any RPM-based system.
Generating Debian Packages
To generate an Debian package for the CA which we created, use the following command:
simpleca% grid-ca-package -d -cadir ~/.globus/simpleCA Creating RPM source tarball... done globus_simple_ca_68ea3306.tar.gz Creating debian binary...dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
The resulting debian package will be placed in the current directory. As
root, you can install this via the dpkg
tool.
Generating GPT Packages
The grid-ca-package
command can also generate GPT packages in
the form similar to previous versions of the Globus Toolkit. This is
done with the -g and -b command-line options. See
grid-ca-package
for more details.
Using a SimpleCA
As a CA, your main task will be to sign certificates. To sign a
certificate request, use the tool grid-ca-sign
. This tool reads
a certificate request (such as those created by
grid-cert-request
) and creates a
certificate signed by the CA certificate with the public key from in the
certificate request. This indicates that you confirm that the identity
of the certificate matches its name. You can use the openssl
command to view the contents of the certificate request.
Examining a Certificate Request
To examine a certificate request, use the command openssl req -text
-in
, as shown in the following example.
simpleca% openssl req -noout -text -in certreq.pem Certificate Request: Data: Version: 0 (0x0) Subject: o=Grid, OU=GlobusTest, OU=simpleCA-elephant.globus.org, OU=local, CN=Joe User Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 79:bd:a7:29:16:77:4c:e9:82:d3:73:a0:25:34:c7: 25:07:67:b3:2d:11:c1:e2:c9:b1:ec:41:20:a7:9a: b7:2f:ee:d4:88:78:14:ff:d4:f2:f9:1b:d3:56:bc: 37:6f:f0:06:ea:b0:6f:70:12:a8:34:ac:8e:be:98: 00:b9:b8:ec:39:b5:6b:23:ad:1b:00:62:4b:cc:79: 97:cc:56:fb:54:7b:03:6d:a7:76:27:4e:ce:bd:94: d0:eb:59:6b:25:c5:30:b0:47:15:bc:11:d5:7e:ff: 04:13:70:de:3b:8f:80:65:ae:63:82:61:38:f9:c6: 03:4a:92:b0:de:6f:bb:0a:bd Exponent: 65537 (0x10001) Attributes: Requested Extensions: Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA Signature Algorithm: sha1WithRSAEncryption 85:70:a6:5d:de:be:61:45:83:48:43:8d:4b:4b:4a:79:79:98: 0d:6c:d4:a9:96:26:41:a4:c2:94:10:92:ad:eb:ad:c5:3c:bf: d6:4e:84:0a:db:46:96:a9:52:5b:90:cc:6a:d1:57:73:27:98: 9e:e2:8c:9a:7f:b4:ab:a8:28:2b:02:98:a2:d8:69:73:5e:12: ad:5b:de:0c:6e:60:e0:0f:2c:ad:8d:b9:59:3b:d3:49:19:52: e0:e1:8a:57:f2:c3:a6:4d:b9:2c:5c:58:ef:0e:59:84:55:8e: 16:fc:f4:39:82:13:6f:28:a9:59:e3:c8:f1:4e:87:75:33:4f: ae:be
In this case, you see a certificate request with the subject
distinguished name o=Grid, OU=GlobusTest,
OU=simpleCA-elephant.globus.org, OU=local, CN=Joe User
.
Signing a Certificate Request
If you are satisfied with the certificate request and are willing to
sign it, use the grid-ca-sign
command to do so. The command will
store a copy of the newly signed certificate in the SimpleCA directory,
so that you can keep track of what you’ve signed, and will also write it
to the value of the -out parameter. Transmit this result file back to
the user which requested the certificate.
grid-ca-sign
simpleca% grid-ca-sign -in certreq.pem -out cert.pem To sign the request please enter the password for the CA key: The new signed certificate is at: /home/simpleca/.globus/simpleCA/newcerts/01.pem
Once you’ve signed the certificate, if it is a user certificate, you must communicate it back to the user, perhaps via email.
Revoking a Certificate
SimpleCA does not yet provide a convenient interface to revoke a signed
certificate, but it can be done with the openssl
command.
simpleca% openssl ca -config ~/.globus/simpleCA/grid-ca-ssl.conf -revoke ~/.globus/simpleCA/newcerts/01.pem Using configuration from /home/simpleca/.globus/simpleCA/grid-ca-ssl.conf Enter pass phrase for /home/simpleca/.globus/simpleCA/private/cakey.pem: Revoking Certificate 01. Data Base Updated
Once a certificate is revoked, you can generate a Certificate Revocation
List (CRL) for your CA, which will be a signed list of certificates
which have been revoked. Sites which use your CA will need to keep the
CRL up to date to be able to reject revoked certificates. This CRL can
be generated with an openssl
command. See ca(1)
for details
about how to control the CRL lifetime and other options.
simpleca% openssl ca -config ~/.globus/simpleCA/grid-ca-ssl.conf -gencrl > CAHASH.crl Using configuration from /home/simpleca/.globus/simpleCA/grid-ca-ssl.conf Enter pass phrase for /home/simpleca/.globus/simpleCA/private/cakey.pem:
The output file CAHASH.crl
(based on the hash of your CA subject
name) should be distributed to sites which trust your CA, so that they
can install it into the trusted certificate directory.
Renewing a CA
The openssl
command can be used to renew a CA certificate. This
will generate a new CA certificate with the same subject name and
private key as before, but valid for a different time interval. This new
certificate packaged and distributed as before using
grid-ca-package
.
simpleca% openssl req -key ~/.globus/simpleCA/private/cakey.pem -new -x509 -days 1825 -out newca.pem -config ~/.globus/simpleCA/grid-ca-ssl.conf You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Level 0 Organization [Grid]: Level 0 Organizational Unit [GlobusTest]: Level 1 Organizational Unit [simpleCA-elephant.globus.org]: Name (E.g., John M. Smith) []:Globus Simple CA
Important
|
The Subject Name of the new certificate must match exactly the previous certificate name, or clients will not recognize it as the correct certificate. |
Security Considerations
Security considerations for SimpleCA
The operator of a CA must protect the private key of the CA. It should not be stored unencrypted or on a network filesystem.
Simple CA enforces the subject name policies in the simple CA’s configuration files. If modified, the signing_policy file distributed to clients of the CA must also be modified.
Troubleshooting your installation
The following is a list of links that take you to information about troubleshooting your installation by component
-
Common Runtime components
-
Security components
-
Data Management components
-
Execution Management components
Detailed Configuration by Component
Security Considerations in GCT 6.2
Common Runtime
Security considerations for XIO
Globus XIO is a framework for creating network protocols. Several existing protocols, such as TCP, come built into the framework. XIO itself introduces no known security risks. However, all network applications expose systems to the risks inherent when outsiders can connect to them. Also included in the XIO distribution is the GSI driver, which provides a driver that allows for secure connections.
Security
Security considerations for GSI C
During host authorization, the toolkit treats host names of the form
hostname-
ANYTHING.edu
as equivalent to hostname.edu
. This means that if
a service was set up to do host authorization and hence accept the certificate
hostname.edu
, it would also accept certificates with DNs
hostname-
ANYTHING.edu
.
The feature is in place to allow a multi-homed host following a
"hostname-interface" naming convention, to have a single host certificate. For
example, host grid.test.edu
would also accept the likes of grid-1.test.edu
or grid-foo.test.edu
.
Note
|
The string ANYTHING matches only the name of the host and not domain
components. This means that If a host was set up to accept |
In GCT 6.2, it is possible to disable this behavior, by setting the enviornment variable GLOBUS_GSSAPI_NAME_COMPATIBILITY
to STRICT_RFC2818
.
MyProxy Security Considerations
You should choose a well-protected host to run the myproxy-server on. Consult with security-aware personnel at your site. You want a host that is secured to the level of a Kerberos KDC, that has limited user access, runs limited services, and is well monitored and maintained in terms of security patches.
For a typical myproxy-server installation, the host on which the myproxy-server is running must have /etc/grid-security created and a host certificate installed. In this case, the myproxy-server will run as root so it can access the host certificate and key.
GSI-OpenSSH Security Considerations
GSI-OpenSSH is a modified version of OpenSSH and includes full OpenSSH functionality. For more information on OpenSSH security, see the OpenSSH Security page.
Data Management
Security Considerations
Ways to configure your server
There are various ways to configure your GridFTP server that provide varying levels of security. For more information, see Installing GCT 6.2.
Firewall requirements
If the GridFTP server is behind a firewall:
-
Contact your network administrator to open up port 2811 (for GridFTP control channel connection) and a range of ports (for GridFTP data channel connections) for the incoming connections. If the firewall blocks the outgoing connections, open up a range of ports for outgoing connections as well.
-
Set the environment variable GLOBUS_TCP_PORT_RANGE:
export GLOBUS_TCP_PORT_RANGE=min,max
where min,max specify the port range that you have opened for the incoming connections on the firewall. This restricts the listening ports of the GridFTP server to this range. Recommended range is 1000 (e.g., 50000-51000) but it really depends on how much use you expect.
-
If you have a firewall blocking the outgoing connections and you have opened a range of (local) ports, set the environment variable GLOBUS_TCP_SOURCE_RANGE:
export GLOBUS_TCP_SOURCE_RANGE=min,max
where min,max specify the port range that you have opened for the outgoing connections on the firewall. This restricts the GridFTP server to bind to a local port in this range for outbound connections. Recommended range is twice the range used for GLOBUS_TCP_PORT_RANGE, because if parallel TCP streams are used for transfers, the listening port would remain the same for each connection but the connecting port would be different for each connection.
Note
|
If the server is behind NAT, the |
If the GridFTP client is behind a firewall:
-
Contact your network administrator to open up a range of ports (for GridFTP data channel connections) for the incoming connections. If the firewall blocks the outgoing connections, open up a range of ports for outgoing connections as well.
-
Set the environment variable GLOBUS_TCP_PORT_RANGE
export GLOBUS_TCP_PORT_RANGE=min,max
where min,max specify the port range that you have opened for the incoming connections on the firewall. This restricts the listening ports of the GridFTP client to this range. Recommended range is 1000 (e.g., 50000-51000) but it really depends on how much use you expect.
-
If you have a firewall blocking the outgoing connections and you have opened a range of ports, set the environment variable GLOBUS_TCP_SOURCE_RANGE:
export GLOBUS_TCP_PORT_RANGE=min,max
where min,max specify the port range that you have opened for the outgoing connections on the firewall. This restricts the GridFTP client to bind to a local port in this range for outbound connections. Recommended range is twice the range used for GLOBUS_TCP_PORT_RANGE, because if parallel TCP streams are used for transfers, the listening port would remain the same for each connection but the connecting port would be different for each connection.
Additional information on Grid Community Toolkit Firewall Requirements is available here.
Execution Management
Security Considerations
Gatekeeper Security Considerations
GRAM5 runs different parts of itself under different privilege levels.
The globus-gatekeeper
runs as root, and uses its root privilege
to access the host’s private key. It uses the grid map file to map Grid
Certificates to local user ids and then uses the setuid()
function to change to that user and execute the
globus-job-manager
program
Job Manager Security Considerations
The globus-job-manager
program runs as a local non-root account.
It receives a delegated limited proxy certificate from the GRAM5 client
which it uses to access Grid storage resources via GridFTP and to
authenticate job signals (such as client cancel requests), and send job
state callbacks to registered clients. This proxy is generally
short-lived, and is automatically removed by the job manager when the
job completes.
The globus-job-manager
program uses a publicly-writable
directory for job state files. This directory has the sticky bit
set, so users may not remove other users files. Each file is named by a
UUID, so it should be unique.
Fork SEG Module Security Considerations
The Fork Scheduler Event Generator module uses a globally writable file for job state change events. This is not recommended for production use.
Usage Statistics
The following components collect usage statistics as outlined here (along with information about how to opt-out): Usage Statistics in GT
Data Management Usage Statistics
Usage statistics collection by the Globus Alliance
GridFTP-specific usage statistics
The following GridFTP-specific usage statistics are sent in a UDP packet at the end of each transfer, in addition to the standard header information described in the Usage Stats section.
-
Start time of the transfer
-
End time of the transfer
-
Version string of the server
-
TCP buffer size used for the transfer
-
Block size used for the transfer
-
Total number of bytes transferred
-
Number of parallel streams used for the transfer
-
Number of stripes used for the transfer
-
Type of transfer (STOR, RETR, LIST)
-
FTP response code — Success or failure of the transfer
Note
|
The client (globus-url-copy) does NOT send any data. It is the servers that send the usage statistics. |
We have made a concerted effort to collect only data that is not too intrusive or private and yet still provides us with information that will help improve and gauge the usage of the GridFTP server. Nevertheless, if you wish to disable this feature for GridFTP only, use the -disable-usage-stats option of globus-gridftp-server. Note that you can disable transmission of usage statistics globally for all C components by setting "GLOBUS_USAGE_OPTOUT=1" in your environment.
Also, please see our policy statement on the collection of usage statistics.
Execution Management Usage Statistics
Usage statistics collection by the Globus Alliance
GRAM5-specific usage statistics
The following usage statistics are sent by default in a UDP packet (in addition to the GRAM component code, packet version, timestamp, and source IP address) at the end of each job.
-
Job Manager Session ID
-
dryrun used
-
RSL Host Count
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_UNSUBMITTED
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_FILE_STAGE_IN
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_PENDING
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_ACTIVE
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_FAILED
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_FILE_STAGE_OUT
-
Timestamp when job hit
GLOBUS_GRAM_PROTOCOL_JOB_STATE_DONE
-
Job Failure Code
-
Number of times status is called
-
Number of times register is called
-
Number of times signal is called
-
Number of times refresh is called
-
Number of files named in file_clean_up RSL
-
Number of files being staged in (including executable, stdin) from http servers
-
Number of files being staged in (including executable, stdin) from https servers
-
Number of files being staged in (including executable, stdin) from ftp servers
-
Number of files being staged in (including executable, stdin) from gsiftp servers
-
Number of files being staged into the GASS cache from http servers
-
Number of files being staged into the GASS cache from https servers
-
Number of files being staged into the GASS cache from ftp servers
-
Number of files being staged into the GASS cache from gsiftp servers
-
Number of files being staged out (including stdout and stderr) to http servers
-
Number of files being staged out (including stdout and stderr) to https servers
-
Number of files being staged out (including stdout and stderr) to ftp servers
-
Number of files being staged out (including stdout and stderr) to gsiftp servers
-
Bitmask of used RSL attributes (values are 2^id from the gram5_rsl_attributes table)
-
Number of times unregister is called
-
Value of the
count
RSL attribute -
Comma-separated list of string names of other RSL attributes not in the set defined in
globus-gram-job-manager.rvf
-
Job type string
-
Number of times the job was restarted
-
Total number of state callbacks sent to all clients for this job
The following information can be sent as well in a job status packet but it is not sent unless explicitly enabled by the system administrator:
-
Value of the executable RSL attribute
-
Value of the arguments RSL attribute
-
IP adddress and port of the client that submitted the job
-
User DN of the client that submitted the job
In addition to job-related status, the job manager sends information periodically about its execution status. The following information is sent by default in a UDP packet (in addition to the GRAM component code, packet version, timestamp, and source IP address) at job manager start and every 1 hour during the job manager lifetime:
-
Job Manager Start Time
-
Job Manager Session ID
-
Job Manager Status Time
-
Job Manager Version
-
LRM
-
Poll used
-
Audit used
-
Number of restarted jobs
-
Total number of jobs
-
Total number of failed jobs
-
Total number of canceled jobs
-
Total number of completed jobs
-
Total number of dry-run jobs
-
Peak number of concurrently managed jobs
-
Number of jobs currently being managed
-
Number of jobs currently in the UNSUBMITTED state
-
Number of jobs currently in the STAGE_IN state
-
Number of jobs currently in the PENDING state
-
Number of jobs currently in the ACTIVE state
-
Number of jobs currently in the STAGE_OUT state
-
Number of jobs currently in the FAILED state
-
Number of jobs currently in the DONE state
Also, please see our policy statement on the collection of usage statistics.