Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide (coming soon)
- Migrating from GT2
- Migrating from GT3
Reference
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces (coming soon)
- Resource Properties
- Samples
- Glossary
- Performance Studies (coming soon)
Manuals
Common Runtime
Security
- Non-WS (General) Security
- WS Java Security
- Message-level
- Authz Framework
- CAS
- Delegation Service
- MyProxy
- GSI-OpenSSH
- SimpleCA
- SGAS
Data Mgt
MDS4
Execution Mgt
Table of Contents
The service configuration files such as jndi-config.xml or server-config.wsdd (located under $GLOBUS_LOCATION/etc/<gar>/ directory) may contain private information such as database passwords, etc. Ensure that these configuration files are only readable by the user that is running the container.
The deployment process automatically sets the permissions of the jndi-config.xml and server-config.wsdd files as user readable only. However, this might not work correctly on all platforms and this does not apply to any other configuration files.
The services using subscription persistence API or other basic persistence helper API will store all or part of its persistent data under the ~/.globus/persisted directory. Ensure that the entire ~/.globus/persisted directory is only readable by the user running the container.
A client can potentially invoke a service function that is not formally defined in the WSDL but it is defined in the service implementation class. There are two ways to prevent this from happening:
- Define all service methods in your service class as either
privateorprotected. - Configure appropriate
allowedMethodsorallowedMethodsClassparameter in the service deployment descriptor (please see Configuring Java WS Core for details).
C WS-Core supports secure transport (https) and secure message (just X509 signing, not encryption).
With secure transport,
the entire container must be run over an
https transport. This is done by default for the C container. If
the user does not want security in the container,
or wants to use secure message instead
of secure transport, they should use the
-nosec argument to
globus-wsc-container.
For clients, the secure transport is enabled if the contact URI contains the 'https' scheme instead of 'http', so the client doesn't have to enable or disable it explicitly.
Individual services can be configured with or without message security, but transport security is a characteristic of the entire container (either using ssl or plain tcp). Authentication and authorization of clients is performed using a callback mechanism.
Simply edit the file config.txt where the executable is being
run and turn on ssl.
By default, pyGridWare will look in the user's home directory
for the .globus/usercert.pem and .globus/userkey.pem files.
To use the grid proxy generated by grid-proxy-init, just specify
the /tmp/x509*** as
the certfile and keyfile.
Example pyGridWare/bin/config.txt
[security] ssl = 1 certfile = keyfile =
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.
Under some circumstances, the org.globus.util.Util.setFilePermissions() and the org.globus.util.ConfigUtil.getUID() functions execute an external program; thus, its behavior is influenced by environment variables such as the caller's PATH and the environment variables that control dynamic loading. Care should be used if calling these functions from a program that will be run as a Unix setuid program, or in any other manner in which the owner of the Unix process does not completely control its runtime environment.
Since Java does not provide an API for setting the permissions of a file, the Java CoG Kit will attempt to execute the /bin/chmod program in the background to set the permissions of the given file. If that program cannot be executed for any reason or fails to execute correctly, a proxy file might end up with incorrect file permissions (depending on umask setting). Usually a warning will be displayed if that occurs (especially on Windows since /bin/chmod is not supported on that platform).
pyGlobus has a security module which allows for proxy creation, signing, encryption, and the creation and inquiry of security contexts. Care must be taken when developing applications which use GSI to ensure that authentication information will not be compromised. When creating a security context, one must ensure that the context will have the properties that they desire. For example, should the context use confidentiality of integrity? These concerns are not specific to pyGlobus but rather to any application developer who is using low level security APIs.
During host authorization, the toolkit treats DNs "hostname-*.edu" as equivalent to "hostname.edu". This means that if a service was setup to do host authorization and hence accept the certificate "hostname.edu", it would also accept certificates with DNs "hostname-*.edu".
The feature is in place to allow a multi-homed host folowing a "hostname-interface" naming convention, to have a single host certificate. For example, host "grid.test.edu" would also accept likes of "grid-1.test.edu" or "grid-foo.test.edu".
![[Note]](/docbook-images/note.gif)
Note The wildcard character "*" matches only name of the hostand not domain components. This means that "hostname.edu" will not match "hostname-foo.sub.edu", but will match "host-foo.edu".
Note If a host was set up to accept "hostname-1.edu", it will not accept any of "hostname-*.edu".
A bug has been opened to see if this feature needs to be modfiied.
Client authorization of the server is done after the completion of the operation when GSI Secure Message authentication is used. If you require client authorization to be done prior, use GSI Secure Conversation or GSI Transport security.
During host authorization, the toolkit treats DNs "hostname-*.edu" as equivalent to "hostname.edu". This means that if a service was setup to do host authorization and hence accept the certificate "hostname.edu", it would also accept certificates with DNs "hostname-*.edu".
The feature is in place to allow a multi-homed host folowing a "hostname-interface" naming convention, to have a single host certificate. For example, host "grid.test.edu" would also accept likes of "grid-1.test.edu" or "grid-foo.test.edu".
| Note |
|---|---|
The wildcard character "*" matches only name of the hostand not domain components. This means that "hostname.edu" will not match "hostname-foo.sub.edu", but will match "host-foo.edu". |
| Note |
|---|---|
If a host was set up to accept "hostname-1.edu", it will not accept any of "hostname-*.edu". |
A bug has been opened to see if this feature needs to be modfiied.
The Java security code currently does not enforce secure permissions and, implicitly, file ownership requirements on any of the security related files, e.g. configuration and credential files. It is thus important that administrators ensure that the relevant files have correct permissions and ownership. Permissions should generally be as restrictive as possible, i.e. private keys should be readable only by the file owner and other files should be writable by owner only, and the files should generally be owned by the globus user (the requirements that the C code enforces are documented in Configuration interface).
Also refer to Section 5, “Known Problems” for details on any other open issues.
- The database username/password is stored in the service configuration file and the test properties file. Ensure correct permissions to protect the information.
The current design re-uses the keys associated with the delegation service for each of the proxy certificates delegated to it. During a security review it was pointed out that while this was fine from a cryptographic standpoint, compromising this single long lived key pair may significantly extend the time for which a single intrusion (presuming an exploitable security flaw making the intrusion possible) is effective.
This can be remedied by either frequently regenerating the key pair used by the delegation service, which can be accomplished with a simple cron job, or by generating a new key pair for each new delegation. The later of these approaches requires changes to the design and may be adopted in future versions of the toolkit. For the time being we recommend the former approach should this issue concern you.
The delegation client that is distributed with the toolkit allows for delegation of credentials even when no authorization of the server is done. Also, when using secure message authentication the authorization of the server is done after the completion of the operation. These two scenarios could lead to the delegation of credentials to a malicious server.
To prevent this users should use secure transport (HTTPS) or GSI secure conversation and appropriate client side authorization.
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 is a modified version of OpenSSH and includes full OpenSSH functionality. For more information on OpenSSH security, see the OpenSSH Security page.
Normal considerations in regards to deployment of Grids, Web Services and protection of GSI credentials apply. The bank should preferrably be deployed on a separate machine.
SGAS has been built using an asynchronous allocation/charge model, to minimize the impact on the job submission process and to avoid the possibility for deadlocks or stalls.
The service configuration files such as jndi-config.xml and server-config.wsdd
(located under etc/<gar>/ directory) contain private information such as database passwords and usernames. Ensure that these configuration files are only readable by the user that is running the container.
The deployment process automatically sets the permissions of jndi-config.xml and server-config.wsdd as user readable only. However, this might not work correctly on all platforms and this does not apply to any other configuration files.
RFT stores the transfer requests in a database. Proper security measures need to be taken to protect the access of the data by granting/revoking appropriate permissions on tables that are created for RFT use and other steps that are appropriate and consistent with site specific security measures.
The following are points to consider relative to security:
3.2.1. Two ways to configure your server
We now provide two ways to configuring your server:
- The classic installation. This is equivalent to any FTP server you would normally install. It is run as a root setuid process. Once the user is authenticated, the process does a setuid to the appropriate non-privileged user account.
A new split process installation. In this configuration, the server consists of two processes:
- The control channel (the process the external user connects to) runs as a non-privileged user (typically the globus user).
- The data channel (the process that access the file system and moves the data) runs as a root setuid program as before but is only contacted by the control channel process from a local machine. This means an external user is never connected to a root running process and thus minimizes the impact of an exploit. This does, however, require that a copy of the host cert and host key be owned by the non-privileged user. If you use this configuration, the non-privileged user should not have write permission to executables, configuration files, etc.
There are new authentication options available for the server in GT 4.1.3:
- Anonymous: The server now supports anonymous access. In order for this to work, a configuration switch must explicitly enable it, a list of acceptable usernames must be defined, and an account under which the anonymous user should run must be defined. If the necessary configurations are in place, and the client presents a username that is in the list of acceptable anonymous users, then the session will be accepted and the process will setuid to the anonymous user account. We do not support chroot in this version of the server.
- Username / Password: This is standard FTP authentication. It uses a separate password file, used only by the GridFTP server, *NOT* the system password file.
![[Warning]](/docbook-images/warning.gif) | Warning |
|---|---|
WE HIGHLY RECOMMEND YOU NOT USE THIS. YOU WILL BE SENDING YOUR PASSWORD IN CLEAR TEXT OVER THE NETWORK. |
We do, however, have some user communities who run only on internal networks for testing purposes and who do not wish to deal with obtaining GSI credentials. If you are considering this, we would recommend that you look at Simple CA and set up your own testbed CA. This can be done in less than an hour and then provides you full GSI security.
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 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 outbound ports of the GridFTP server to this range. 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 outbound ports of the GridFTP client to this range. 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 Globus Toolkit Firewall Requirements is available here.
Security recommendations include:
- Dedicated User Account: It is recommended that users create a dedicated user account for installing and running the RLS service (e.g.,
globusas recommended in the general GT installation instructions). This account may be used to install and run other services from the Globus Toolkit. - Key and Certificate: It is recommended that users do not use their hostkey and hostcert for use by the RLS service. Create a containerkey and containercert with permissions
400and644respectively and owned by theglobususer. Change therlskeyfileandrlscertfilesettings in the RLS configuration file ($GLOBUS_LOCATION/etc/globus-rls-server.conf) to reflect the appropriate filenames. - LRC and RLI Databases: Users must ensure security of the RLS data as maintained by their chosen database management system. Appropriate precautions should be made to protect the data and access to the database. Such precautions may include creating a user account specifically for RLS usage, encrypting database users' passwords, etc.
- RLS Configuration: It is recommended that the RLS configuration file (
$GLOBUS_LOCATION/etc/globus-rls-server.conf) be owned by and accessible only by the dedicated user account for RLS (e.g.,globusaccount per above recommendations). The file contains the database user account and password used to access the LRC and RLI databases along with important settings which, if tampered with, could adversely affect the RLS service.
Security recommendations include:
The following paragraph describes our INITIAL IMPLEMENTATION in this first look of the WS RLS interface -- THIS IS NOT INTENDED TO BE A FINAL SOLUTION.
Users of the WS RLS authenticate themselves to the WS RLS in the usual manner based on their credential. The WS RLS uses the WSAA and Authorization Framework to make authorization decisions. Then, the WS RLS uses a single certificate and key file to identify itself to the RLS irregardless of the user accessing the WS RLS. Thus users that can access the WS RLS are given the fixed WS RLS identity to access the RLS. Users accustomed to using RLS may not feel comfortable with this approach -- if it may be an issue for your environment, we suggest that you not use it with your production RLS. If you think of WS RLS as the gating interface to the RLS, as you should, then you should apply the appropriate authorization restrictions at the WS RLS level, which can be done using WSAA. This will in effect achieve a level of authorization similar to that of the RLS.
OGSA-DAI does not provide any security over and above that already provided by the Globus Toolkit. However, consideration must be given to the role mapping which converts a grid credential to a database username/password. OGSA-DAI comes with two basic role mappers: a simple role mapper which accesses a plain text file with this information and one which encrypts the username/password information. More details can be found in the documentation bundled with the documentation. If neither of these schemes are secure enough then it is possible to replace it by implementing a new role mapper interface.
The service configuration files such as the JNDI configuration file,jndi-config.xml,
and the Web service deployment descriptor, server-config.wsdd, located in the
$GLOBUS_LOCATION/etc/globus_wsrf_replicator directory, contain sensitive information
such as database username and password. It is important to ensure that these files are readable
only by the system administrator that is responsible for the container. During deployment, the
permissions on these files are adjusted automatically, however, you should verify the permissions
to ensure that they have been correctly set for your specific platform.
Creating a Replicator requires that the user supply a delegated credential to the DRS
during the initial creation request. The service retrieves the delegated credential from the
Delegation Service and stores it on the file system. As part of the DRS configuration (see
installation and configuration instructions), the user selects a directory to use for storage of
delegated credentials. The default setting is for the DRS to store the file in the system's
designated temporary directory (e.g., /tmp on many platforms). The service sets the
permissions on the temporary file such that it can only be accessed by the user account used to
run the container.
By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.
By default, the WebMDS plugins distributed as part of the Toolkit do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information.
The ResourcePropertyNodeSource
and ResourcePropertyQueryNodeSource
plugins can be configured either to allow users to specify
what resources they want to query or to only allow users to query resources
pre-configured by the web administrator. The standard WebMDS
deployment allows users to specify the resources they want to query;
to disallow this (for example, to ensure that people don't use your
site's bandwidth to view information about some other site's services),
remove the files $GLOBUS_LOCATION/lib/webmds/conf/openEndedRP
and $GLOBUS_LOCATION/lib/webmds/conf/openEndedQuery.
In some applications, control of physical equipment carries the risk of serious property damage or injury. These applications should implement operational security procedures and not rely solely on software security.