I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR
That said, do note the warning on the dynamic toolbox filters page:
[image: <!>] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox .
On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.eric@yandex.ru wrote:
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Okay, thanks for confirming and creating the card.
Yes...it's unfortunate that tool filters will not block tools entirely, but this will get it out of the users' view in one more place.
On 12/17/2013 05:39 PM, Dannon Baker wrote:
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR
That said, do note the warning on the dynamic toolbox filters page:
[image: <!>] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox .
On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.eric@yandex.ru wrote:
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security mechanism.
You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation ( https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping) there is an example of enforcing "dev" only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... )
It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see.
-John
On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker dannon.baker@gmail.comwrote:
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue here: https://trello.com/c/3TxFHkYR
That said, do note the warning on the dynamic toolbox filters page:
[image: <!>] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML manipulation. That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the ToolBoxhttps://wiki.galaxyproject.org/ToolBox .
On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche rasche.eric@yandex.ruwrote:
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied globally and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not their entire set of options and associated documentation. Additionally, that sort of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John,
I've been using the dynamic jobs and they've been working beautifully! (For context, I wrote the initial revision of the Access Control page based off of my readings and experiences setting it up in galaxy).
I, for one, would be in favour of "stronger" filters in addition to the current versions of filtering, mostly due to my/IT's paranoid nature :) The current filters seem to accomplish exactly what they were designed to, and I see no reason to replace them.
On 12/17/2013 06:15 PM, John Chilton wrote:
Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security
mechanism.
You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation (
https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping)
there is an example of enforcing "dev" only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... )
It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see.
-John
On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker
dannon.baker@gmail.comwrote:
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue
here:
That said, do note the warning on the dynamic toolbox filters page:
[image: <!>] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML
manipulation.
That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the
ToolBoxhttps://wiki.galaxyproject.org/ToolBox
.
On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche
rasche.eric@yandex.ruwrote:
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied
globally
and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not
their
entire set of options and associated documentation. Additionally,
that sort
of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
- -- Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu rasche.eric@yandex.ru
Ahh... missed that. Sorry (and thanks for putting together the page :) ). It seems like we are on the same page - I have created a Trello card for 'stronger' toolbox filters.
It occurs to me there may another way to accomplish admin tool functionality - and in an even more "locked down" fashion. I think you may be able to setup another Galaxy process with a similar config but a different tool_config_file setting and it should act as its own handler+web process as well. Then you could configure your proxy so admin requests come through this process - or maybe it could have its own URL, etc.... Maybe this is crazy - I am sure Nate will respond is this is non-sense :).
-John
On Tue, Dec 17, 2013 at 6:26 PM, Eric Rasche rasche.eric@yandex.ru wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John,
I've been using the dynamic jobs and they've been working beautifully! (For context, I wrote the initial revision of the Access Control page based off of my readings and experiences setting it up in galaxy).
I, for one, would be in favour of "stronger" filters in addition to the current versions of filtering, mostly due to my/IT's paranoid nature :) The current filters seem to accomplish exactly what they were designed to, and I see no reason to replace them.
On 12/17/2013 06:15 PM, John Chilton wrote:
Agreed with Dannon, it is a bug that they are showing up in the workflow editor but in general toolbox filters are not meant as a security
mechanism.
You can block access to running specific tools (filtered or not) using dynamic job destinations. (Under dynamic job destinations documentation (
https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping)
there is an example of enforcing "dev" only tools for a specific set of e-mails as well as an example of how to get a list of admin users in a dynamic job destination. These could be combined to enforce admin only tools. I think there has been some other posts on this topic... )
It is true that one can still see the options of such tools, this is something we will have to think about... Perhaps a 'stronger' filter, though I think this variant of filtering should still be an option, there are many use cases for allowing users to run tools they cannot see.
-John
On Tue, Dec 17, 2013 at 5:39 PM, Dannon Baker
dannon.baker@gmail.comwrote:
This sounds like a bug; the primary toolbox and workflow editor toolbox should reflect the same set of tools (exception being workflow-specific control steps, etc). I've created a trello card to track this issue
here:
That said, do note the warning on the dynamic toolbox filters page:
[image: <!>] Filters will only hide Tools from the User Interface, they are still available and can be made visible by means of HTML
manipulation.
That said these feature is not a security feature, it is intended to separate multiple groups of Tools and simplify the
ToolBoxhttps://wiki.galaxyproject.org/ToolBox
.
On Tue, Dec 17, 2013 at 6:27 PM, Eric Rasche
rasche.eric@yandex.ruwrote:
I'm running the stable copy of galaxy and noticed that some custom, administrative tools (and otherwise tools which should be restricted in access due to licensing/etc.) were showing up in normal user's toolboxes inside the workflow editor.
I feel that this is a bug, as the tool filters should be applied
globally
and not just in terms of what tools users are restricted from seeing in the normal toolbox.
For me, this presents a problem as I strongly believe any administrative tools that exist should leak as little information as possible--not
their
entire set of options and associated documentation. Additionally,
that sort
of information leakage isn't acceptable by my organisation's policies.
Do I have my instance misconfigured or is this an actual bug? I have my galaxy configured according to https://wiki.galaxyproject.org/Admin/Config/Access%20Control
$ hg head changeset: 11242:9d4cbf2a1c13 branch: stable tag: tip user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Fri Dec 06 16:28:31 2013 -0500 summary: Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf.
changeset: 11216:c458a0fe1ba8 parent: 11213:6d633418ecfa parent: 11215:f79149dd3d35 user: Nate Coraor nate@bx.psu.edu nate@bx.psu.edu date: Mon Nov 04 14:56:57 2013 -0500 summary: Merge security fix for filtering tools from stable/next-stable.
$ hg summary parent: 11242:9d4cbf2a1c13 tip Add missing destination long arg to cli runner's Torque plugin and fix an incorrectly used PBS option in the sample job conf. branch: stable commit: 4 modified, 34 unknown update: (current)
Thank you, Eric Rasche
Programmer II Center for Phage Technology Texas A&M University
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu rasche.eric@yandex.ru -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSsOvMAAoJEMqDXdrsMcpVA7wP/RfgVwvG/8zUw1NvSA+XXy28 fEC9oIICRjizka5QoKxyXqjYIkYxFBBnq1FMErnlB4ietldjO4h8jxN1WhWG7EmQ HnESF500XF7/pxmKfhTdU6nG5hh5TGTtFG5HYqd3S0eA3fdrAn6AE6Ejmi+seuFT +OpFRV0lj/n+ew91GAJwLbv4GNyOuiXELkdEBSFIDkQMeUF8oOXZJsKyoywkHA2g U0f/WGnIjn0SGq2LdfMjQkz2eggeJ9t5T6jzwqYxsI9tCOWusCuLDrmbQCwJs+iU O1kZgvo4pJmxok3btcKiL9zUxjfp+uke/fE/kydedWV2sT3pyrb8rRxrT5Tvmlql TW6mJ/5ReISl6bf+2MWj5MB3hDh/nQ4kr1c5R/GAoEwCyA34VUK3nBbyAvYKNzwY EO/kgIlzDyOX/HxpAvyAM51RnqSYPXZFuR0+vqBEf1w7bAngjy/1hrvWTBA/S35p rjBI8d2PZreh5fFoDEFFWTfuPcTkA6BE5kh8uH2WH/ssqtxr690bNns0jAsMlHh9 ohVCWhar7cue+ERY/eZfT4nbdxsJ+FoavsEvvpx2Jx4LHP6GX1ckYSfTcL1tPV1E dNAzNr5J2hWirL+MHUtlPyVvVrrCVkWUNe9v0aNTLsM9hjKZGgMxhVH8GpP00Pd/ lXR63Be6E2cfiEHoDS0F =3rQT -----END PGP SIGNATURE-----
galaxy-dev@lists.galaxyproject.org
-
Dannon Baker -
Eric Rasche -
John Chilton