Summary: | Create allowlist of plugins allowed to be installed by Web UI | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Plugin architecture | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | martin.renvoize |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | 25672 | ||
Bug Blocks: |
Description
David Cook
2020-05-04 23:38:31 UTC
I am thinking the whitelist would contain an entry like "Koha::Plugin::Com::ByWaterSolutions::CSV2MARC". However, another plugin could pretend to be that same one. A malicious plugin could pretend to be a popular plugin and thus defeat the whitelist. With Bug 24632, that would be far less likely. You could set up your plugin keys so that only Bywater Solutions is trusted, and then only "Koha::Plugin::Com::ByWaterSolutions::CSV2MARC" is allowed on the whitelist. It is still possible to have collisions if you trust more than one provider and they use the same name, but that is unlikely due to the naming conventions Kyle created from the start. Different vendors should use their company names like "Koha::Plugin::Com::ProsentientSystems::OaiHarvester" (which one day I hope to be a real thing). Plus, if we did start using vendor/community Github/Gitlab as repositories, we could potentially limit the likelihood of people sourcing plugins from obscure locations. This looks a bit tougher than I was thinking but should still be doable... I think if I do a Module::Pluggable search for "Koha::Plugin" in between these following two lines and then compare to an allowlist... that should do the trick. my $ae = Archive::Extract->new( archive => $tempfile, type => 'zip' ); unless ( $ae->extract( to => $plugins_dir ) ) { The challenge is how to define this configuration, but I think I could use the same idea I had at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28498#c4 Set up a configuration file called /etc/koha/plugin-allowlist.yml and then point each Koha instance at that file via koha-conf.xml. That also allows for the possibility to have 99% of instances using the generic allow list while some instances could be configured using /etc/koha/sites/INSTANCE/plugin-allowlist.yml to provide a different list. (I still want to replace koha-conf.xml, but creating Koha::Config->file() with caching layers is beyond what I want to do right now...) I've updated the summary because I think we only need to define an allowlist that inhibits the Web UI. I think we should allow sysadmins to install whatever they want. (I'm also not too concerned with people uninstalling plugins at this point. I think that would be better handled by Bug 28499.) |