FAQs and misconceptions about gLExec

Here is a list of common question and misconceptions regarding gLExec.

Question : Is gLExec the similar to like sudo?

Answer : No. Sudo is generically meant to execute a program or script with root-privileges. gLExec will not perform any task besides the actual user switch with root-privileges. All operational task within gLExec are performed with the privileges of either the calling (system/Unix) user (e.g. reading the proxy) or the mapped user (writing the proxy and executing the command).

Question : Is gLExec like Apache's suexec?

Answer : No. gLExec does implement all the safety checks of suexec, but suexec lacks the advanced Grid credential authentication, authorization and account mapping features that we've build-in. For example: gLExec's uses LCAS as a pluggable authorization framework and it uses LCMAPS as pluggable framework to perform the local account mapping. The LCMAPS layer can also be extended to use SCAS, Argus or GUMS. gLExec can also be restricted for a limited list of accounts from a whitelist.

Question : Is my Batch System able to handle identity switching during a job run?

Answer : Processes like the pbs_mom run with root-privileges and thus have all the privileges to manage all job types. Please have a look at the Batch System Interoperability experiences with different types of Batch Systems and a non-gLExec testing tool.

Question : gLExec runs with elevated privileges, isn't it dangerous to offer gLExec on my Worker Nodes?

Answer : Security measures build from the ground up prevent any use of the elevated privileges. Both the user process calling gLExec and the executed command with the target identity are unable to use gLExec's privileges. Multiple build-in security measures prevent a target user to be mapped to a root account or root group.

Question : Who controls the gLExec run mode i.e. choice to run in logging-only mode or setuid mode?

Answer : The site is in full control of this choice. The system administrator will need to install the right configuration settings for the mapping process to function properly and will need to install gLExec with the required setuid-bit enable on the binary with the root owenership.

Question : Can every user on my system call gLExec?

Answer : It is completely up to you. gLExec allows you to whitelist users, but you can disable this restriction.

We offer a few options from within gLExec:

1. Per account white listing: In the glexec.conf file write user_white_list = okoeroo
2. Per pool of account white listing: In the glexec.conf file write user_white_list = .atlpilot
3. By letting the calling account be a member of the special Unix group 'glexec'.
4. You could whitelist every account by using the wildcard *. There are good motivations why you want to do this and it should not blindly be regarded as a security risk. Please read ahead in the motivation section for details about this.

Note: Even the 'root' account itself needs to be whitelisted to be able to work with gLExec. For more information see the glexec and glexec.conf man pages for the user_white_list option.

Question : If a user is able to use gLExec can I now just execute a command?

Answer : After being authorized, Yes. Based on the presented credentials gLExec will use LCAS locally for an authorization decision, followed by LCMAPS which is able to call remote services like SCAS, GUMS or Argus for an authorization decision.

Question : Isn't gLExec a risk to my infrastructure?

Answer : Taking the use case of Multi User Pilot Job Frameworks as an example; the Pilot Job frameworks have moved the front door of your site from the CE to the WN. gLExec on the Worker Nodes gives back control to the Sites which they have on their CEs and regular jobs. With the identity switching feature enabled it can give the VOs the opportunity to not be regarded as one user i.e. when one user in the VO goes rogue the entire VO is suspected and might be disallowed as a whole from a site.

Motivations

We've invited multiple vulnerability assessment teams to look at gLExec. They've assessed the code in a lot of detail and written multiple reports about the quality of the code and the vulnerabilities that were in them. The overall conclusions were that we've done a very good job over time in creating a very secure tool that exactly does what we advertise. We've build upon our experiences in the LCG-CE, gridFTPd and other security related tools that we've made over time. We have a strong drive to make gLExec even safer than it already is without compromising the usability of the tool.