GLExec

gLExec is a program that acts as a light-weight 'gatekeeper'. gLExec takes Grid credentials as input. By taking the local site policy into account it authenticates and authorizes the credentials. For extra safety gLExec is capable of creating a new execution sandbox based on the Grid credentials. Besides the yes/no control point functionality in the logging-only mode it can create identity specific sandboxes in the identity-switching mode.

Deployment: Installation and setups

• gLExec on the Worker Nodes
  • Using generic per-node pool accounts or a shared map database
  • Using the SCAS
  • Batch System Interoperability
• Deployment Scenarios in EGEE and OSG
• Secure installation considerations

Debugging and How To's

• Debugging hints

• How To's
  • Transient jobs (working with data from pilot to payload) describes how you may go about managing a target workload's transient area.
  • The gLExec wrapper scripts

FAQ

• FAQs and misconceptions about gLExec

Online documentation (on other sites)

• Exit codes of gLExec
• Man pages of gLExec
• Service Reference Card for gLExec

gLExec is a program to make the required mapping between the grid world and the Unix notion of users and groups, and has the capacity to enforce that mapping by modifying the uid and gids of running processes. It used LCAS and LCMAPS for access control and the mapping engine. It can both act as a light-weight 'gatekeeper' replacement, and even be used on the worker node in late-binding (pilot job) scenarios. Through the LCMAPS SCAS client a central mapping and authorization service (SCAS, or any interoperable SAML2XACML2 service) can be used.

The description, design and caveats are described in the paper to the CHEP conference.

Local services, in particular computing services offered on Unix [5] and Unix-like platforms, use a different native representation of the user and group concepts. In the Unix domain, these are expressed as (numeric) identifiers, where each user is assigned a user identifier (uid) and one or more group identifiers (gid). At any one time, a single gid will be the .primary. gid (pgid) of a particular process, This pgid is initially used for group-level process (and batch system) accounting. The uid and gid representation is local to each administrative domain.

Deploying gLExec on the worker node

Secure installation considerations

To prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, an out side source must be able to verify the installation. Consider the use of tripwire, rpm --verify <rpm package name> or something. At the moment the packages that we produce are without the setuid-bit on root. This means that an admin would need to run YAIM or the chmod command manually to get the setuid bit enabled on root. Because the deployment needs this post installation manipulation on the executable the rpm --verify (and Debian package equivalent) will inherently fail, because not only the hash of the binary also the file permissions are verified.

It's pointless for gLExec to provide a safe test in itself to signal its binary to be, for example, be world writable. If this test fails, you would send a strong signal to a potential attacker to rewrite the binary. On Linux systems and most Unix system the setuid-root bit is stripped when the image is rewritten, making it a harmless executable at best. However, this is not desired, but unavoidable to provide such a self test in gLExec itself.

Using gLExec in a pilot job framework

When you use glexec with transient directories and input sandboxes, it's important that you create a writable directory for your target job, and you do this in a safe and portable way. We provide a proof-of-principle imple,entation on hwo to create such a directory, and clean up after yourself here:

• https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/pdpsoft/trunk/grid-mw-security/glexec/util/mkgltempdir/

See also the more extensive text on GLExec TransientPilotJobs.

Need to Know's

The gLExec executable is installable in two ways, with an without the setuid (file system) bit on root. With the setuid-bit enabled on root, this effectively means that gLExec is being executed with root privileges. Without the setuid or setgid bits on root the gLExec executable is like any other regular executable.

The safety features of gLExec are implemented with great care to avoid misuse and exploitation by anybody who executes it. As gLExec is typically installed with a setuid bit on root, this effectively means that anybody on the system is able to execute something with root privileges for a brief moment of time to perform the user switch.

A couple of safety features that are build in the gLExec tool are:

• The LD_LIBRARY_PATH, LD_RUN_PATH and other LD_* environment variables are removed from the process environment by the Operating System before the first line of gLExec code is executed by a Unix and Linux system. Only the /etc/ld.so.conf{.d/}, RPATH settings and other system specific paths are used and resolved. This statement holds for any setuid or setgid executable.

• The rest of the environment is stripped off by gLExec. There are a couple of environment settings that can easily lead to a root exploit in the standard library of a Unix and Linux system. Only the GLEXEC_* environment variables are kept. There is an option in the glexec.conf file to preserve more variables, but these must be selected with great care and setup by each System Administrator on all their machines.

• If the target user is authorized and when a mapping and Unix process identity switch the HOME and X509_USER_PROXY will be rewritten. Their value will contain the paths that are relevant for the target user account.

• The target user process has the Unix identity as mapped by LCMAPS. This could be from a separate set of pool accounts, or the regular set of pool accounts as given by the same user credentials from an LCG-CE or CREAM-CE. It could be a poolaccount defined locally on the machine. The only assumption that holds is that the target user account has the privileges that are appointed to them by the local site administrator.

How To's

To help you master the obstacles of gLExec's security we offer some interesting How To material:

• GLExec TransientPilotJobs describes how you may go about managing a target workload's transient area.
• GLExec Environment Wrap and Unwrap scripts describes how you can preserve the environment variables between the calling process of gLExec and the user switched side of gLExec. For example: to preserve the environment variables from a Pilot Job Framework, through gLExec and into Pilot Job Payload.