[Bug 23890] New: Plugins that utilise possibly security breaching hooks should warn
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Bug ID: 23890 Summary: Plugins that utilise possibly security breaching hooks should warn Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org Bug 22706 introduces a hook for plugins which would allow plugin authors to nefariously steal user credentials. We should implement a whitelist/blacklist approach for plugin hooks such that the end-user is warned about such possible issue upon plugin installation. Perhaps we should even implement something akin to access permissions as found on the android app store where you can grant specific rights to a plugin upon it first asking for said capability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #1 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Questions to note. 1) When/Where should warnings appear? - During install, with an abort option? - After install, with an uninstall option? - Always as a message in the 'installed plugins' table? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22706 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I've changed my mind on this one... whilst going through existing hooks and trying to pick which methods potentially exposed us to nefarious code I pretty much decided that they all could. + 'opac_online_payment' => '1', + 'opac_online_payment_end' => '1', + 'opac_online_payment_begin' => '1', + 'to_marc' => '1', + 'edifact_transport' => '1', + 'edifact_process_invoice' => '1', + 'edifact_order' => '1', + 'edifact' => '1', + 'opac_head' => '1', + 'opac_js' => '1', + 'intranet_head' => '1', + 'intranet_js' => '1', + 'intranet_catalog_biblio_enhancements_toolbar_button' => '1', As such, I think warning on some but not others could actually lead us to worse situation where inexperienced system administrators are lulled into a false sense of security. In reality, I feel we need a cleaner delivery method for plugins as a community and perhaps a signing procedure to state a certain level of trust/quality. This is something I've wanted to work on for some time but not had a moment to implement to date. As such, I don't believe this should hold up bug 22706. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22832 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #2)
As such, I think warning on some but not others could actually lead us to worse situation where inexperienced system administrators are lulled into a false sense of security.
In reality, I feel we need a cleaner delivery method for plugins as a community and perhaps a signing procedure to state a certain level of trust/quality. This is something I've wanted to work on for some time but not had a moment to implement to date.
I totally agree with this. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |22832 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22832 [Bug 22832] Require plugins to specify the methods they implement -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Martin Renvoize from comment #2)
As such, I think warning on some but not others could actually lead us to worse situation where inexperienced system administrators are lulled into a false sense of security.
In reality, I feel we need a cleaner delivery method for plugins as a community and perhaps a signing procedure to state a certain level of trust/quality. This is something I've wanted to work on for some time but not had a moment to implement to date.
As such, I don't believe this should hold up bug 22706.
I agree. The password hook can clearly be used for nefarious purposes, but *any* plugin could be bad actor. Outside that hook, all data, subroutines and methods are available to plugins. I think this is an issue inherent in *any* pluggable system, Koha or otherwise. I really like the idea of a trusted plugin authorities with signing. I think we need to discuss what this will look like, and where we need to start. I've thought about this a lot over time. I've always imagined a Wordpress like ability for Koha to search for and install plugins directly from the admin interface. That still doesn't help us describe a backend for such a system. I see a few options: 1) Integrate this into Mana 2) Keep it outside Mana, but in another community project 3) A distributed plugin management model 3 is what I keep coming back to in my mind. What I imagine is an interface in Koha to define plugin repositories. I think we could leverage the release systems in GitHub and GitLab to power such a system. So, for example, if I want to be able to search and install plugins from ByWater Solutions, I'd add https://github.com/bywatersolutions/ to my plugin source targets. Koha would then search for repos prefixed with "koha-plugin" ( which seems to be a general convention followed by most plugin developers ). At this point it would be trivial for Koha to pull data about the plugin from GitHub. One addition to plugins that would facilitate this is to add a package.json file with contents similar to what is in the metadata of the plugin file removing the need to download the plugin to know metadata about it like the supported Koha versions. Indeed, it would allow Koha to skip over plugins that are known to not work with that version of Koha! The same could be done for GitLab I'm sure. Thoughts? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Kyle M Hall from comment #4)
I've thought about this a lot over time. I've always imagined a Wordpress like ability for Koha to search for and install plugins directly from the admin interface. That still doesn't help us describe a backend for such a system.
As a user/librarian, I think that this sounds awesome. As a vendor/administrator, I think that this sounds awful. Since plugins are a stability/security risk, I don't want to allow users to be able to install plugins. That said, I see the utility of plugins, so I - as a system administrator - want to be able to install trusted plugins on Koha (probably from the CLI, since we don't really have an administrator layer in the web UI). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Kyle M Hall from comment #4)
3 is what I keep coming back to in my mind. What I imagine is an interface in Koha to define plugin repositories. I think we could leverage the release systems in GitHub and GitLab to power such a system.
So, for example, if I want to be able to search and install plugins from ByWater Solutions, I'd add https://github.com/bywatersolutions/ to my plugin source targets. Koha would then search for repos prefixed with "koha-plugin" ( which seems to be a general convention followed by most plugin developers ). At this point it would be trivial for Koha to pull data about the plugin from GitHub. One addition to plugins that would facilitate this is to add a package.json file with contents similar to what is in the metadata of the plugin file removing the need to download the plugin to know metadata about it like the supported Koha versions. Indeed, it would allow Koha to skip over plugins that are known to not work with that version of Koha!
The same could be done for GitLab I'm sure.
Thoughts?
I don't really like the sound of that, as it seems hacky and too Git-specific. Maybe we should look around at other examples before we re-invent the wheel? I will just note that I envision a system where we have a list of public keys and a list of repositories (quite like APT really). You search the repository and when you try to install a plugin, you check the plugin file's signature against the public key, and only verified plugins are installed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #7 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I envisage somewhat of a mix of the two.. keys administered by system administrators via the command line and searchable repositories via the UI for end users. That combination should allow us to have vendor trusted plugins that are whitelisted at the serverside level but open up the searchability and intallability options to the end users. I did like the idea of a centralised plugin directory allowing for reviews of plugins and ease of discovery and have had that side of things in mind for a while.. but again, that could utilise a similar philosophy of searching git hosting for plugins that match a certain criteria. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think the discussion is not if the users can install plugins themselves or not - they already can. This is a discussion on how to make sure they get better information about the plugins and if they are trustworthy. Also allowing admins to whitelist certain repositories... and I think those are good ideas. I like the idea for the plugins to provide some general information about them. Maybe if we had plugins that were limited to only using what the APIs offer, we could have a list of what they use as an indicator of potential damage. But as our plugins can do 'anything', it's much harder. We could maybe ask developers to include information about data that will be changed by their plugin in some way? A list of core methods and hooks used? I always liked how the DokuWiki system for plugins worked. They are listed in the DokuWiki DokuWiki, with their repository/zip URLs. Then you can search that from within your own installation, get info and also download and install if a URL has been provided, alternatively, you can still upload zip files manually for installing plugins provided elsewhere. (https://www.dokuwiki.org/plugins) So maybe we could have a central directory of available plugins with descriptions etc. This would allow us to add a form of rating, QA and similar in the future, but still allowing people to do development using their preferred tool. The DokuWiki directory also allows you to see how often a plugin has been installed by others, as an indicator of those that are popular/widely used. This could be an easy way to have a first indicator of 'quality'. They also include a 'report bugs' link in their directory that is helpful. As another security measure we could allow admins to 'whitelist' plugins or sources in the directory locally and block the upload of zip files, so users get a limited view of plugins supported/checked by their admins/providers. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_20_05_target -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Tools |Plugin architecture Assignee|martin.renvoize@ptfs-europe |koha-bugs@lists.koha-commun |.com |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_05_candidate |rel_20_11_target -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- I like all those ideas, Katrin. Bug 24632 would allow installation of only plugins signed by trusted providers. Bug 25370 would allow installation of only plugins with certain package names. Turning off manual plugin uploads might also be a good idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_11_target | CC| |jonathan.druart@bugs.koha-c | |ommunity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org