Menu
▾
▴
#36 Security hole using local submitter must be documented
This is a split from #2058372 (https://sourceforge.net/tracker/?func=detail&aid=3489905&group_id=506195&atid=2058372).
Enabling the local submitter in gUSE open an enormous security hole in the web portal running it. Every user can gain administrator access to the web portal. e.g. on Tomcat installation he has read access to tomcat-users.xml as well as any file containing database credentials and grid certificates including private keys and passwords. Thus, he can impersonate any portal user at least during the authentication process of the grid middleware.
Unfortunately this fact is not documented. Contrary, the DCI bridge documentation reads:
"There are several advantage and disadvantage of the usage of a local submitter.
Pro: Job submission is fast, response time is short, certificate is not needed - ideal for quick tests.
Con: It burdens the limited resources: may spoil the overall throughput capacity of the gUSE therefore its
usage is not suggested in public portals, and due restraint is recommended even at sporadic use."
This can be read in the following way: The local submitter is not suitable for computing intensive tasks, but useful for short tasks as the generation of configuration files. Though this is a totally valid conclusion of the documentation its implementation destroys all security means of the portal and the grid.
Please, remember that software is not used how it is intended to be used. The users concern is: „What can I use it for?“ And you shold consider that one of the great advantages of the human brain is the ability to forget information that is unused for a long time. If someone wants to prepare some configuration files using shell scripts he can and will look if there is a fast way of doing that. The current text in the documentation suggests that the local submitter is suitable for this task, which is wrong.
I miss something like the string: „For testing environments only! Do not use in productive or publicly availlable environments, not even for testing! It imposes a severe security hole. Disable this plugin as soon as possible as it allows every user to gain full administrator access of the portal including access to private keys of certificates, database passwords and, consequently, confidential user data. If a user by accident runs a script executing "rm -rf / tmp" (this is not the worst case) he will propably delete your entire gUSE installation.“
• In the manual everywhere the word “local“ is mentioned.
• In the DCI Bridge in the tab of the local submitter (Propably it would be sufficient to add a big red word to the Icon of the local submitter: „dangerous!“)
Note: This suggestion is already a compromise. I really think that the local submitter should not go into the normal distribution. You can provide it for download to developers. All other administrators should get meaningful error messages in the logs in case something is wrong with the configuration. That is much more helpful than the local submitter.
At least with my installation problems the local submitter was not very helpful. Far less than the security problems it cauuses.
Hi all,
Please note that there could be legitimate usage of the local submitter in some scenarios, even on public production gateways. One example is the AutoDock portal. On this portal the local submitter is active and executes very short non-frequent jobs. This is ideal for the speed, and as the jobs are very non-frequent (1 very short job for every 1,000-10,000 job workflow), it does not create too much extra load on the server.
The security issue is also addressed. On this portal only "end-user" accounts can be created. This means that no "power-users" (besides the portal admins themselves) are allowed for this portal. Therefore, none of the users can create new workflows or can remap the execution of any components of a workflow to different resources. Users can only execute pre-prepared workflows (after importing them) with their custom input parameters. This portal is connected to a public desktop grid, so there is no certificate involved either.
I believe that these kind of gateways and scenarios will become more and more typical. Many communities are moving away from generic gateways and creating customized gateways for their communities. The above mentioned AutoDock gateway is one example where the target user community does not know what workflows are or how to create them.
Best regards,
Tamas
Last edit: Tamas Kiss 2013-01-20
Dear keinstein,
Thank you for your report. The usage of local submitter is not permitted in default case in DCI Bridge. The usage of local submitter is not recommended in production level, actually. The documentation will completed with additional information..
Thank you,
please consider also changing the icon. The configuration interface of the DCI bridge is intuitive enough that people tend to forget about consulting the manual at a later time. (That is the sense of intuititve user interfaces.)
Dear keinstein,
Thanks.
We'd like to refine our previous information:
The local submitter is permitted in default case after installation of system for initial testing at local level. However, it is strictly recommended as you mentioned only for testing environment because of security aspectts. Therefore the permission deny is recommennded for users after testing process. This security note completes the documentation.
Hi gottdank,
please be careful about your wording. As far as I can understand gUSE has neither an authentication layer nor an authorisation layer. Thus, talking about permittion will just confuse people.
So far I didn't discover anything that is named “permition deny“ in this context. If I'm wrong, give a detailed description, please.
As far as I can see a function that is not loaded can not be executed. Thus, after some expertments with gUSE 3.4, it might be sufficiently save to follow the following procedure (in staccato):
DCI Bridge Configuration → Local → Middleware settings → enable plugin: disabled
As long as it doesn't enable itself again this an improvement, at least.
For older gUSE versions it might not as easy. Try the following procedure in gUSE 3.3:
1. enable local
2. create workflow and configure a job to execute locally
3. disable local
4. try to execute the workflow configured in 2.
If that job doesn't fail because of missing local disabling is not save. If you manage to disable it, it would be nice if you can document, how it has to be done.
Hi keinstein,
The detail description about importance of local disabling will complete the manual. Thanks for your precise note.
Tibor
Hi,
Was it ever considered to use separate credentials for the local execution to at least isolate the possible damage and protect the installation?
Thanks
Gr,
Mark
Hi all,
I support Mark's idea!
Lorenz
ETHZ
Hi All,
Here is the gUSE team's answer for the question of Mark:
“Was it ever considered to use separate credentials for the local execution to at least isolate the possible damage and protect the installation?”
Originally, the local execution was completely hidden for the external world and was only permitted for the internal members of the gUSE team for testing purposes. We have found very useful to test the basic functionalities of the portal (like workflow definition and execution) independently from the unreliable grid infrastructures. Once we were sure that everything was working in the local environment we switched off the local execution, configured the portal with the target grid (or other type of DCI) and continued the test there. Therefore the local execution was never meant to be used in a public portal and hence we never considered to use separate credentials for the local execution.
All these are clearly written in the gUSE_Install_Wizard_Manual_v3.5.2.pdf manual:
“2. Security
Notes:
Do not forget deactivate the local submitter immediately after the test, as the usage of the local resource represents a major security risk (it is provided only for testing purposes).”
We understand that under certain circumstances it would be useful to use the local execution mode. However, beyond the security problems there are many other issues why we do not recommend it. For example, a malicious or inexperienced user can use up all the resources of the portal machine so other users will be starved.
If despite all these arguments the gUSE user community wants the usage of the local execution facility I have to refer my previous message titled as “Apply for a gUSE developer role” where I expressed the gUSE team’s wish to extend the gUSE developer community with new external volunteer members who can help us to solve issues that are beyond the development capacity of the gUSE team.
We are happy to accept volunteer contributors to solve this local execution issue, too.
Peter Kacsuk
Head of gUSE Team
Hi Peter,
Thanks for putting this in context (and sorry for the late reply :-)
This issue can be solved in many ways of course, but I was thinking of whether there is a low-hanging-fruit solution.
One possible approach I could think of is to create a "guselocal" user. Then configure sudo to allow user "guse" to become "guselocal" and then run all local jobs through sudo.
This would require minimal configuration and code changes and some documentation additions.
This would still mean that all local jobs run with the same privileges as each other, but they wont be able to destroy the guse installation.
Of course this would also not solve the "resource starvation" problem, but if that becomes an issue people should probably just install a batch system on the local machine.
If people support this idea than I'm willing to make the necessary changes.
Gr,
Mark
Hi all,
Please note that there could be legitimate usage of the local submitter in some scenarios, even on public production gateways. One example is the AutoDock portal. On this portal the local submitter is active and executes very short non-frequent jobs. This is ideal for the speed, and as the jobs are very non-frequent (1 very short job for every 1,000-10,000 job workflow), it does not create too much extra load on the server.
The security issue is also addressed. On this portal only "end-user" accounts can be created. This means that no "power-users" (besides the portal admins themselves) are allowed for this portal. Therefore, none of the users can create new workflows or can remap the execution of any components of a workflow to different resources. Users can only execute pre-prepared workflows (after importing them) with their custom input parameters. This portal is connected to a public desktop grid, so there is no certificate involved either.
I believe that these kind of gateways and scenarios will become more and more typical. Many communities are moving away from generic gateways and creating customized gateways for their communities. The above mentioned AutoDock gateway is one example where the target user community does not know what workflows are or how to create them.
Best regards,
Tamas