TWiki> EGEE Web>SA3>ServiceReferenceCards>GLExec (revision 2)EditAttachPDF

gLExec on WN, CE and anywhere else

Functional description

The gLExec system, used in combination with the LCAS site-local authorization system and the LCMAPS local credential mapping service, provides an integrated solution for site access control to grid resources. With the introduction of gLExec, the submission model can be extended from the traditional gatekeeper models, where authorization and credential mapping only take place at the site’s ‘edge’. Retaining consistency in access control, gLExec allows a larger variety of job submission and management scenarios that include per-VO schedulers on the site and the late binding of workload to job slots in a scenario where gLExec in invoked by pilot jobs on the worker node. But it is also the mapping ingredient of a new generation of resource access services, like CREAM.

Daemons running

None. The SCAS daemon is usually on a separate node

Init scripts and options (start|stop|restart|...)

No init scripts are needed for the gLExec. All the options are explained in the glexec.1 and glexec.conf.5 manpages that are located in the RPM package distribution (will be published soon).

Configuration files location with example or template

The glexec.conf configuration file path is set at compile due to the security implication related to operating gLExec in a safe way. LCAS and LCMAPS are used by gLExec for the authorization and mapping processing. Without providing the glexec.conf file, gLExec will use build in defaults to work. The build in default locations for LCAS and LCMAPS are /opt/glite/etc/lcas/lcas-suexec.db and /opt/glite/etc/lcmaps/lcmaps-suexec.db. These build-in values can be altered at compile time. To view how glexec is compiled, execute glexec as the full root user with the option -V: /opt/glite/sbin/glexec -V This will list all the build-in definitions.

More commonly the glexec.conf file is configured to explicitly declare the location for the LCAS and LCMAPS configuration files.

Logfile locations (and management) and other useful audit information

The build-in log file location for glexec is /var/log/glexec/glexec_log. This can be changed at compile time. Execute glexec with -V to get the build-in definitions. Alternatively the log file may be set to a different location by setting the option 'log_file' with a path in the glexec.conf. By default gLExec will log to this file or the build-in path to the log file. The logs for LCAS and LCMAPS can be merged or split separately by setting the 'lcas_log_file' and 'lcmaps_log_file' options in the glexec.conf. Alternatively syslog can be used. When setting the glexec.conf option 'log_destination' to the value 'syslog' the glexec, LCAS and LCMAPS log information will all be merged into the syslog facility.

Open ports

There are no open ports created. The only network related interaction results from the syslog client-side interface and the SCAS client-side interface.

Possible unit test of the service

We're working a test script that is able to test and check a setup, but also could run through a series of tests to verify that the glexec is functional or not.

Where is service state held (and can it be rebuilt)

Not applicable. It runs as a suexec, su or sudo like executable.

Cron jobs

N/a.

Security information

Access control Mechanism description (authentication & authorization)

Proxy certificate verification in the verify proxy plugin. LCAS framework, using the user_ban plugin. The LCAS VOMS plugin can be used to whitelist or blacklist*. The * is that this requires the use of GACL to express it.

How to block/ban a user

Can be done at the LCAS instance on the host itself. For Worker Node scenarios we recommend the LCAS banning being done at the SCAS service to be able to manage just one central repository to ban users for all gLExec interactions.

Network Usage

Will only need network interaction when using syslog and when using the SCAS facility. The latter one is a mutual authenticated SSL session to the SCAS daemon using the credentials of the gLExec executor. In pilot job scenarios, this identity differs from the identity to which glexec will map the process.

Firewall configuration

Outbound connection for syslog and outbound connection (SSL) to the SCAS daemon, typically TCP port 8443. In this case 'Outbound' means, from the node to the SCAS service, not the outside world.

Security recommendations

File permissions
The recommended file ownership and permission is:
  • 6555 root.glexec /opt/glite/sbin/glexec
  • 0440 root.glexec /opt/glite/etc/glexec.conf

File permissions (explanation)
Use the setuid mode of gLExec to be able to create a privilege separation between the executor (pilot job executor or production manager) of gLExec and the payload mapped identity to prevent privilege escalation and strict boundaries between the two responsible people on behalf of which a certain process is being executed. Also, do not setup glexec.conf with world-readible permissions. It's not needed and prevents distribution of security interesting information.

File permission verification
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 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.

Security incompatibilities

Unknown. If there is any, please let the developers of gLExec know about problems or incompatibilities.

List of externals (packages are NOT maintained by Red Hat or by gLite)

When installing the SCAS-client LCMAPS plugin to be able to connect to a SCAS daemon, the SAML2-XACML2 protocol implementing library is created by Globus.

Other security relevant comments

Environment Variables
There is a build in functionality available to preserve specific environment variables in gLExec. We advise strongly against the use of any environment variable other then $X509_USER_PROXY on a Worker Node or $X509_USER_CERT and X509_USER_KEY. These variables will be used when gLExec is required to interact with the SCAS service. Some variables may interfere with the security mechanisms build in the gLExec, hence the clean up by gLExec.

To preserve environment variables to be used in the child process executed by gLExec, users must use published workaround to preserve the environment variables. This might become somewhat easier in the future, but the operating system will always wipe the LD_LIBRARY_PATH, LD_RUN_PATH and other LD_* environment variables from any setuid enabled program before executing it. This last thing is unpreventable by gLExec.

More detailed information and "How To"s are available at: http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/GLExec

Whitelist

The gLExec executable can only be used by users in the whitelist. There are two ways of getting in the whitelist. The build-in method can be used in absence of a glexec.conf configuration file. The build-in method is to look at the user's primary and secondary Unix group that are currently associated with the user. One of the groupnames must be equal to 'glexec'. This will allow the user to continue running gLExec. The other (more advertised) method is to configure the line user_white_list in the glexec.conf configuration file. The user_white_list line holds a list of comma separated user names that are allowed to call gLExec. When the name starts with a dot, e.g. .glexec, the name denotes a pool account and matches all user names starting with glexec, followed by one or more digits. Thus .glexec matches the regular expression: glexec[0-9]+.

Typically in our infrastructure the poolaccount that a especially setup to allow for pilot job framework execution are listed in the whitelist only.

Note: also root is 'just an account' and needs to be whitelist in the special case that you wish to test or use gLExec with root privileges.

Utility scripts

N/a (yet). Please contact us if something useful is required/wished.

Location of reference documentation for users

The manpages will be published soon and linked in the URL: http://www.nikhef.nl/grid/lcaslcmaps/

Location of reference documentation for administrators

A lot of information on glexec, LCAS, LCMAPS and SCAS is published at http://www.nikhef.nl/grid/lcaslcmaps/ The manpages will be published soon and linked in the URL: http://www.nikhef.nl/grid/lcaslcmaps/

-- OscarKoeroo - 01 Jun 2009

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2009-06-16 - OscarKoeroo
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback