gx-map-security - Security considerations in gx-map
The gx-map system has two major parts: a set of programs used to maintain a Globus grid-mapfile, and a program to maintain a Globus certificates directory (both located under the /etc/grid-security/ directory by default). Both components address important security concerns, and a serious bug in either could allow an attacker to compromise a system.
This man page discusses the security aspects of both subsystems.
The gx-map system is designed to maintain the grid-mapfile and certificate files used by Globus. These files are critical to the security of any system providing Globus services, and any errors in these files (deliberate or otherwise) can open security holes, either allowing a user to access another user's account, or allowing an outside attacker to gain access to the system.
A single Unix account must be chosen to install, own, and run the gx-map system. If possible, this should be an account dedicated to the purpose (such as ``gxmap''). Access to this account must be carefully secured.
By installing, deploying, and using this software, you are trusting its author with the security of your system. (You can limit this trust by using ``paranoid mode''; see below.) I promise that I have done my best to make this software as secure as possible. I do not promise that I have succeeded. See the LICENSE file for the legalese. (This isn't anything unusual; the same is true of most security-related software.)
Historically, in the past several years that various versions of gx-map have been used at SDSC and other sites, there has been only one exploitable security hole that I'm aware of. This hole only occurred in rare circumstances, was exploited exactly once (in my own testing with the permission of the target user), and was corrected in the following release.
Be careful out there.
As discussed in the gx-map(7) man page, grid-mapfile maintenance is performed in three phases. The gx-request client program allows an end user or an administrator to submit a request for a grid-mapfile update. The gx-check-requests program, executed from a privileged account, validates any new requests and appends any valid ones, with annotations, to a log file, requests.log. The gx-gen-mapfile program reads the requests.log file and generates a new grid-mapfile as necessary.
The gx-map system allows a user to request an update to the grid-mapfile, and applies the update automatically, without operator intervention. The worst-case scenario would be a bug that allows a user to map an arbitrary DN (Distinguished Name) to an account other than his own; this would allow unauthorized access to the account.
A user is allowed to map an arbitrary DN to his own account, but may not map a DN to any other account. No checking is done to confirm that the user can use the certificate corresponding to the DN. This does allow a possible denial-of-service attack: an attacker could deliberately map a victim's DN to the attacker's account, denying the victim access to his own account. But this would give the victim access to the attacker's account.
If an attacker manages to break into a victim's account (by stealing a password, exploiting an operating system bug, or even using an unattended terminal), he'll be able to run the gx-request command on the victim's behalf. The gx-map system doesn't validate the user beyond confirming that the command is run by the user; it doesn't prompt for the user's password.
All transactions are logged. In fact, a transaction log (the gx-map-data/requests.log file) is the central data structure for the system. If an attacker did manage to create a bogus mapping, the log would record the time of the request and the name of the host on which it was done.
The gx-request command is unprivileged. It runs under the user's account, and it creates a request file in the world-writable gx-map-data/new-requests subdirectory under the gx-map installation directory. A user could easily grab a copy of the gx-request script and modify it, or manually create a bogus request file. Therefore the gx-map system does not depend on gx-request operating properly. The information in the request file is not trusted; it is carefully validated by the gx-check-requests command. Bad requests are detected and separately logged.
The gx-check-requests command checks for new request files in the gx-map-data/new-requests directory. This is a privileged (but not setuid) command, to be executed only by the owner of the gx-map installation. The requests.log file is owned by the gx-map owner, and cannot be modified by anyone else.
For an ``add'' or ``remove'' request, the request file specifies the distinguished name and the Unix user name to which it is to be mapped or unmapped.
For a request submitted by a non-administrative user, gx-check-requests confirms that the specified Unix user name matches the account that owns the request file. For an administrative request, it confirms that the file is owned by a gx-map administrator (this is typically the ``gxmap'' or ``globus'' account).
Most Unix filesystems do not allow non-root users to use chown. The gx-map security model depends on this. If non-root chown were allowed, a user could create a bogus request file mapping his own DN to another user, and then change the file's ownership to the target account.
Some Unix systems do allow non-root chown, either by default or via a configuration option. The gx-check-requests command checks for this (by attempting to chown a temporary file) and refuses to run if non-root chown is allowed.
The gx-map system in general depends on Unix filesystem semantics, in particular that the content or ownership of a file can be affected only by the owner of the file. For use across multiple systems within a site, it can be convenient to store gx-map's data files on a shared NFS-mounted filesystem. There are legitimate concerns about the security of NFS in general. Each site will have to make its own decision about any tradeoffs between security and convenience.
The gx-gen-mapfile command generates a new grid-mapfile from the gx-map-data/requests.log file created by gx-check-requests. No special privileges are required, other than the ability to read the input file.
If gx-gen-mapfile wrote directly to the grid-mapfile, there would be some danger of a program seeing a partially constructed grid-mapfile. To avoid this, gx-gen-mapfile writes to a temporary file in the same directory, then renames the file. This should make it impossible for any program to see a partial grid-mapfile.
By default, gx-gen-mapfile checks the generated grid-mapfile into an RCS directory. This provides a history of any changes, in addition to the information in the requests.log file.
gx-gen-mapfile writes the generated grid-mapfile to a location specified on the command line. Typically the location is the /etc/grid-security directory, or /etc/grid-security/grid-mapfile can be set up as a symbolic link to the target location. If you prefer, you can generate the grid-mapfile in a separate directory, and copy it to /etc/grid-security/grid-mapfile only after confirming that it's correct. This ``paranoid mode'' avoids any possible bugs in gx-map, at the expense of not updating the grid-mapfile automatically.
The gx-ca-update command maintains files in the certificates directory, normally /etc/grid-security/certificates. This directory contains two or three files for each supported CA (Certificate Authority): the signing certificate xxxxxxxx.0, the signing_policy file xxxxxxxx.signing_policy, and the (optional) CRL (Certificate Revocation List) xxxxxxxx.r0. (xxxxxxxx is replaced by the 8-digit hexadecimal hash value for the CA.)
The worst-case scenario would be allowing an attacker to install bogus CA files. It would be fairly straightforward to generate a bogus signing certificate with the same subject name as a recognized CA, and use it to issue a bogus user certificate. If the forged CA certificate can be installed in /etc/grid-security/certificates, Globus will accept it. The permissions on the /etc/grid-security and /etc/grid-security/certificates directories must not allow updates by untrusted users. (The gx-map system does not currently confirm this.)
For each CA, the gx-map system includes a cadesc file, etc/gx-map/ca-config/xxxxxxxx.name.cadesc, containing information about the CA. This information includes the URLs from which the required files can be downloaded, the MD5 and SHA1 fingerprints of the signing certificate, and several other things.
gx-ca-update normally installs the xxxxxxxx.0 and xxxxxxxx.signing_policy files only once, on the initial run. The xxxxxxxx.0 file is downloaded from the specified URL nd checked against the MD5 and SHA1 fingerprints specified in the cadesc file. (This should guard against an attacker hacking the web server and substituting a bogus certificate). The signing_policy file is not downloaded; instead, it is generated from information in the cadesc file. This allows for a more restrictive signing policy than specified by the CA; it also ensures that the installed signing_policy file works with all version of Globus from GT2 to GT4.
Certificate and CRL files are downloaded using the curl command.
The curl command is invoked with the "--insecure" option, which
causes it to ignore any server certificates for an https URL.
This is necessary (or at least convenient) for web servers that
use unrecognized certificates. Since gx-ca-update validates
the checksums and signatures for all the files it downloads, this
shouldn't create a security problem.
The xxxxxxxx.r0 file (the Certificate Revocation List) is downloaded and installed whenever it's updated. This is actually the main reason for the existence of the gx-ca-update command. The CRL is downloaded from the URL specified in the cadesc file. gx-ca-update then confirms that the CRL was cryptographically signed by the corresponding CA certificate before installing it.
If a current CRL is installed, Globus will reject any certificate listed in the CRL. If the CRL has expired, all certificates issued by the CA will be rejected. If the CRL is removed, all certificates issued by the CA will be accepted (including certificates that have been revoked).
By default, if an up-to-date CRL is not available (e.g., because the web server is down), gx-ca-update will leave the expired CRL in place. It can optionally remove the CRL just before it expires; this allows continued use of certificates, but it's insecure. gx-ca-update has a number of command-line options to control its behavior. Those that might compromise security require the user of an explicit ``-UNSAFE'' option.
gx-request(1), gx-check-requests(8), gx-gen-mapfile(8), gx-ca-update(8), gx-map-requests-log(5)
Keith Thompson, San Diego Supercomputer Center, <kst@sdsc.edu>
See the file LICENSE in the gx-map distribution, installed in the etc/gx-map subdirectory.