Difference between revisions of "FAQs and misconceptions about gLExec"

From PDP/Grid Wiki
Jump to navigationJump to search
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Here is a list of common question and misconceptions regarding gLExec.
 
Here is a list of common question and misconceptions regarding gLExec.
  
 +
== Comparisons ==
  
'''Question''' : ''Is gLExec the similar to like [http://www.gratisoft.us/sudo/readme.html sudo]?''
+
'''Question''' : ''Is gLExec similar to [http://www.gratisoft.us/sudo/readme.html 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).
+
'''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 tasks within gLExec are performed with the privileges of either the calling (system/Unix) user (e.g. reading the proxy), the glexec user/group (e.g. reading the config file) or the mapped user (writing the proxy and executing the command).
  
  
 
'''Question''' : ''Is gLExec like Apache's [http://httpd.apache.org/docs/2.0/suexec.html suexec]?''
 
'''Question''' : ''Is gLExec like Apache's [http://httpd.apache.org/docs/2.0/suexec.html 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 execution can be restricted to a limited list of accounts from a whitelist, it 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]], [https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework Argus] or [https://www.racf.bnl.gov/Facility/GUMS/1.4/ GUMS].
+
'''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]], [https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework Argus] or [https://www.racf.bnl.gov/Facility/GUMS/1.4/ GUMS]. gLExec can also be restricted for a limited list of accounts from a whitelist.
  
 +
== Infrastructure ==
  
'''Statement''' : ''Is my Batch System able to handle identity switching during a job run?''
+
'''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 [http://www.nikhef.nl/grid/lcaslcmaps/glexec/osinterop testing tool].
 +
 
 +
 
 +
'''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.
  
'''Response'''  : 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 [https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/GLExec#Batch_system_interoperability Batch System Interoperability] experiences with different types of Batch Systems and a non-gLExec [http://www.nikhef.nl/grid/lcaslcmaps/glexec/osinterop testing tool].
 
 
 
  
 
'''Question''' : ''gLExec runs with elevated privileges, isn't it dangerous to offer gLExec on my Worker Nodes?''
 
'''Question''' : ''gLExec runs with elevated privileges, isn't it dangerous to offer gLExec on my Worker Nodes?''
Line 22: Line 29:
  
  
'''Question''' : ''Who controls the gLExec run mode i.e. choice to run in '''Logging-only''' mode or '''setuid''' mode?''
+
'''Question''' : ''Isn't gLExec a risk to my infrastructure?''
  
'''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.
+
'''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.
  
 +
== Privileges and Privilege Separation ==
  
'''Question''' : ''Can everybody on my system call gLExec?''
+
'''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.  
 
'''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:
 
We offer a few options from within gLExec:
# Per account white listing: In the [http://www.nikhef.nl/grid/lcaslcmaps/glexec/glexec.conf.5.html glexec.conf] file write '''user_white_list = okoeroo'''
+
# Per account white listing: In the [[Man pages of gLExec#The man page for the glexec.conf configuration file|glexec.conf]] file write '''user_white_list = okoeroo'''
# Per pool of account white listing: In the [http://www.nikhef.nl/grid/lcaslcmaps/glexec/glexec.conf.5.html glexec.conf] file write '''user_white_list = .atlpilot'''
+
# Per pool of account white listing: In the [[Man pages of gLExec#The man page for the glexec.conf configuration file|glexec.conf]] file write '''user_white_list = .atlpilot'''
 
# By letting the calling account be a member of the special Unix group 'glexec'.
 
# By letting the calling account be a member of the special Unix group 'glexec'.
 
# 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.
 
# 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.
 
By using external services like [[SCAS]], GUMS and [[Argus]] to make this decision:
 
* Use LCAS in the SCAS
 
* Use GUMS
 
* Use Argus
 
  
 
Note: Even the 'root' account itself needs to be whitelisted to be able to work with gLExec.
 
Note: Even the 'root' account itself needs to be whitelisted to be able to work with gLExec.
For more information see the [http://www.nikhef.nl/grid/lcaslcmaps/glexec/glexec.1.html glexec] and [http://www.nikhef.nl/grid/lcaslcmaps/glexec/glexec.conf.5.html glexec.conf] man pages for the user_white_list option.
+
For more information see the [[Man pages of gLExec#The man page for the gLExec executable|glexec]] and [[Man pages of gLExec#The man page for the glexec.conf configuration file|glexec.conf]] man pages for the user_white_list option.
 
 
  
'''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.
+
'''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]], [https://www.racf.bnl.gov/Facility/GUMS/1.4/ GUMS] or [https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework Argus] for an authorization decision.
  
 
== Motivations ==
 
== 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.
 
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.

Latest revision as of 11:48, 27 August 2012

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

Comparisons

Question : Is gLExec similar to 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 tasks within gLExec are performed with the privileges of either the calling (system/Unix) user (e.g. reading the proxy), the glexec user/group (e.g. reading the config file) 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.

Infrastructure

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 : 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 : 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 : 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.

Privileges and Privilege Separation

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.

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.