Difference between revisions of "FAQs and misconceptions about gLExec"
| (4 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== Comparisons == | == Comparisons == | ||
| − | '''Question''' : ''Is gLExec | + | '''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 | + | '''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). |
| Line 16: | Line 16: | ||
'''Question''' : ''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 [ | + | '''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]. |
| Line 33: | Line 33: | ||
'''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. | '''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 | + | == Privileges and Privilege Separation == |
'''Question''' : ''Can every user on my system call gLExec?'' | '''Question''' : ''Can every user on my system call gLExec?'' | ||
| Line 40: | Line 40: | ||
We offer a few options from within gLExec: | We offer a few options from within gLExec: | ||
| − | # Per account white listing: In the [ | + | # 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 [ | + | # 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. | ||
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 [ | + | 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. |
| Line 52: | Line 52: | ||
'''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. | '''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 09: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:
- Per account white listing: In the glexec.conf file write user_white_list = okoeroo
- Per pool of account white listing: In the glexec.conf file write user_white_list = .atlpilot
- 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.
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.
