Description

glite-GLEXEC_wn

New version of glite-GLEXEC_wn

gLExec 0.7.0 changes:

the changes made in this version are in order to make the code more secure and consist of bug fixes. Every effort is made to preserve backwards compatibility with the previous release 0.6.8-3.

• new glexec.conf options: vomsdir certdir which can be used to pass X509_VOMS_DIR and X509_CERT_DIR variables to LCAS/LCMAPS.
• rewritten environment handling:
  • gLExec sets up PATH, X509_USER_PROXY, HOME, USER, LOGNAME
  • the target user now always have a valid X509_USER_PROXY variable set pointing to a proxy usable by him/her.
  • GLEXEC_TARGET_PROXY will be set for the target user, but should NOT be relied on. It is implemented for backwards compatibility only.
  • all variables starting with MALLOC_ will be stripped from the environment and cannot be whitelisted. This is a mandatory security measure.
• proxy variables:
  • When unset, GLEXEC_SOURCE_PROXY will default to the value of GLEXEC_CLIENT_CERT
  • When GLEXEC_TARGET_PROXY is unset a default value for the target X509_USER_PROXY will be used which depends on whether switching or logging-only mode is configured: Switching-mode: /tmp/x509up_u<uid>.glexec.XXXXXX where <uid> is the target uid, and XXXXXX is a combination of 6 random letters. Logging-only-mode: the value of the variable will be equal to the value of GLEXEC_SOURCE_PROXY or its default, but no file is copied. This behavior guarantees that proxy files are not unwillingly overwritten or be unreachable.
• In logging-only mode, the correct target environment is set up, and a chdir to the homedir of the calling user is performed. I.e. the environment variables set by gLExec have meaningful values. As noted above, unless GLEXEC_TARGET_PROXY is explicitly set, no proxy file is copied in this mode.
• Permissions on proxy files should be at most rwx for user, i.e. 0700. They can be referenced using symlinks.
• The glexec.conf can now also be a symlink. In switching mode, the real config file must be owned by user root or glexec and must either be owned by group glexec or not be group readable. In this mode privileges are dropped to glexec.glexec, so the file must be readable by either the user glexec or members of the group glexec, but not by others: root.glexec / 440 glexec.glexec / 440 or 400 glexec.root / 400 In logging only mode the file must be worldreadable and be owned by user and group root or glexec. In all modes it must not be writable by anyone else than user.
• Added man page information about the backlog_path configuration option.
• The gLExec default log destination is now syslog, since this is a much more reliable default, being always present, userspace accessible, and available from the program start.
• Errors during execve are now also logged and not only send to stderr.
• There are many valid combinations of permissions for /opt/glite/sbin/glexec and the config file /opt/glite/etc/glexec.conf, we advise:

  Switching mode: 
     -rws--x--x 1 root root 12345 2010-02-29 12:34 glexec 
     -r-------- 1 glexec root 123 2010-02-29 12:34 glexec.conf 
  
  Logging-only mode:
    -rwx--x--x 1 root root 12345 2010-02-29 12:34 glexec 
    -r--r--r-- 1 glexec root 123 2010-02-29 12:34 glexec.conf

  Note that these settings are also possible on a NFS mount.

  Also note that YAIM will still install gLExec with the following permissions: (which are still valid, and are also possible on an NFS mount):

  Switching mode:
    -r-sr-sr-x 1 root root 12345 2010-02-29 12:34 glexec
    -rw-r----- 1 root glexec 123 2010-02-29 12:34 glexec.conf
  
  Logging-only mode:
    -r-xr-xr-x 1 root root 12345 2010-02-29 12:34 glexec
    -rw-r--r-- 1 root glexec 123 2010-02-29 12:34 glexec.conf
  

LCMAPS 1.4.11-2 and its plugins changes:

• Logging output in the LCMAPS framework and all plug-ins:
  • All (legacy) plug-ins are less verbose in their logging output. Some log lines are expensive to construct and flood the logfile.
  • Messages regarding the plug-in load are deemed to be too verbose and this is now pushed down to higher debug levels. To the best of our knowledge, these message where never used by log tailing services or tools.
  • At the end of each LCMAPS-run a new block of information is pushed to show which credentials have lead to a mapping. Note: not all information is made available from the PEP-C and SCAS plug-ins. See the SCAS service or PEPd logs for all mapping details that were not extracted, it will show up in those services. Example LCMAPS with VOMS plug-in producing the mapping result:

  Mar 2 18:01:36 asen glexec[18186]: LCMAPS CRED FINAL: DN:"/O=dutchgrid/O=users/O=nikhef/CN=Oscar Koeroo"->mapped uid:'2006',pgid:'2000',sgid:'2000'
  Mar 2 18:01:36 asen glexec[18186]: LCMAPS CRED FINAL: FQAN:"/dteam/Role=NULL/Capability=NULL"->mapped group:2000(dteam) Mar 2 18:01:36 asen glexec[18186]: LCMAPS CRED FINAL: FQAN:"/dteam/ne/Role=NULL/Capability=NULL"->mapped group:2001(dteamNE) Mar 2 18:01:36 asen glexec[18186]: LCMAPS CRED FINAL: FQAN:"/dteam/ne/SE/Role=NULL/Capability=NULL"->mapped group:2002(dteamNESE)

• New features in the LCMAPS PEP C plug-in (used for Argus):
  • This version is officially supporting the Argus 1.1 service
  • It's capable of sending and receiving messages that confirm to both the Grid WN profile and the Grid Interoperability profile.
  • The type of message send to the PEPd is profile dependent and is therefore configurable per profile. By default the Grid WN profile from Switch is used.
  • A new option is introduced to explicitly select the profile used for sending credential information: "--profile <profile version>". The <profile version> currently accepts the values " http://authz-interop.org/profile/1.1" ; and " http://glite.org/xacml/profile/grid-wn/1.0" ;. * A new restriction: The plug-in requires the presence of libpep-c.so version > 1.3.0 due to the required Interoperability to Grid WN profile PIP that is served from the libpep-c.so in it.
  • It will propagate its capabilities as a XACML standard compliant attribute to the Argus service. This is needed for the EES and nonintrusive to the current, past and future Argus services.
• Changes in the LCMAPS framework:
  • The evaluation manager component, responsible for the execution order of the plug-ins, has been updated to not prematurely clear the intermediate credential data. In the case where there are more then one execution policies configured and when the calling service or tool explicitly wishes to execute the policy N-1 (all, but not the last), then the credential data for the final (failed) mapping summary would have been cleared prematurely.
• Changes in the posix_enf plug-in:
  • The output of the posix_enf plug-in was verbose without good reason. This historic artifact is now removed from the most verbose logging level.
  • Two new log lines are now always shown in the log to be able to trace the mapping sequence. Compressing a 40+ lines into a one-liner.
  • In general the following line is printed when the posix_enf has successfully switched to a user account: LCMAPS 1: 2010-02-22.10:35:59-16046 : lcmaps_plugin_posix_enf-plugin_run(): post-id-switch: uid=40237(dteamprd007),euid=40237(dteamprd007),gid=40237(dteam),egid=40238(dteam)
  • When the posix_enf plug-in is used in a setuid-enabled environment, e.g. gLExec on the WN or CE, then the following two log lines are written, this is to show the from and too mapping information: LCMAPS 1: 2010-02-22.10:35:59-16046 : lcmaps_plugin_posix_enf-plugin_run(): pre-id-switch: uid=500(okoeroo),euid=0(root),gid=500(okoeroo),egid=0(root),sgid=10(wheel),sgid=500(okoeroo) LCMAPS 1: 2010-02-22.10:35:59-16046 : lcmaps_plugin_posix_enf-plugin_run(): post-id-switch: uid=40237(dteamprd007),euid=40237(dteamprd007),gid=40237(dteam),egid=40238(dteam)
• Changes in the SCAS-client plug-in:
  • If the SCAS client plug-in failed to contact any of the configured SCAS services then it will report a successful plug-in execution.
  • To go in to detail about this fix: It broke the flow in the LCMAPS plug-in driver. There is no security risk due to multiple safe guards build in following plug-ins and the LCMAPS framework itself that will fail if there are insufficient mapping result presented.
• Changes to both the sets of Basic and VOMS plug-ins:
  • The vo-mapfile, grid-mapfile and gridmapdir sequences in the VOMS and Basic plug-ins are revised to log the reasons of failure. There was no proper way of logging the reasons for the mapping failure. There are various states that could occur and all are described in the least verbose logging level e.g. the pool is not available and the pool is full.
• Change in the Verify-Proxy plug-in:
  • The Proxy Lifetime enforcement and VOMS Lifetime enforcement are function again.
  • New option: --only-enforce-lifetime-checks. This new option will skip the proxy certificate chain verification stage and will only enforce the lifetime check on the chain and the VOMS credentials.
  • Detailed information about how to use the Proxy and VOMS Lifetime enforcement can be found here: https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Verify-proxy
  • Short configuration example for a service or tool that uses the full verify-proxy functionality:

  verify_proxy = "lcmaps_verify_proxy.mod" " -certdir /etc/grid-security/certificates" " --max-voms-ttl 48:00"
  " --max-proxy-level-ttl=L 1d-00:05" " --max-proxy-level-ttl=0 7d-00:05"

• Short configuration example for a service or tool that doesn't require the full certificate chain check again as it has been performed by the SSL connection's authentication process, e.g. a gridftpd or globus gatekeeper, and is only interested in the Lifetime enforcement:

  verify_proxy = "lcmaps_verify_proxy.mod" " -certdir /etc/grid-security/certificates" " --only-enforce-lifetime-checks" " --max-voms-ttl 48:00"
  " --max-proxy-level-ttl=L 1d-00:05" " --max-proxy-level-ttl=0 7d-00:05"

• Bugs already checked and completed. Some bugs have already been addressed in a previous versions of LCMAPS.
  • When using VOMS credentials from two VOMS service sources, the second set was lost in the mapping process.
  • The logging to file feature appends the date and time. There was an offset of 1 month in the logging to file setting.
  • Rogue RPATHs were set into our libraries by ETICS. This has been averted in an emergency patch last year.

Patch #3767: [ yaim-core ] yaim-core 4.0.12 SL5/x86_64

New release of yaim core containing a set of bug fixes and new features:

• Can now configure the GSI callout to call the ARGUS PEP client.
• Avoid mistakenly removing all the services from gLiteservices file.
• Fix GLOBUS_TCP_PORT_RANGE setting on the SL5 tarball UI.
• Correct unset for shell functions in clean-grid-env-funcs.sh
• Make config_bdii_only return non zero in case of error
• Fixes for installing the UI tarball on CernVM.
• Allow general use of the 'nickname' field in the VOMSES settings.
• Add yaim core RPM dependency on perl
• Allow use of pool accounts with up to 4 digits
• Fix grid-env.sh manipulation when running a single yaim function
• Fix gridmap dir group on WMS
• Change the CE_INBOUNDIP and CE_OUTBOUNDIP defaults in site-info.def to be valid and imply the correct (upper) case.
• Call setup-openssl for VDT 1.10.

Fixed bugs

Updated rpms

The RPMs can be updated using yum via

• via apt: yum update
• or via a download from:
  
  http://glitesoft.cern.ch/EGEE/gLite/R3.2/glite-GENERIC/sl5/x86_64/RPMS.updates/

Service reconfiguration after update

Service must be reconfigured.

Service restart after update

Not needed.

How to apply the fix

1. Update the RPMs (see above)
2. Update configuration (see above)
3. Restart the service if necessary (see above)