Bug 24632 - Plugins should support simple signing for security/verifiability
Summary: Plugins should support simple signing for security/verifiability
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Plugin architecture (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords:
Depends on: 23975
Blocks:
  Show dependency treegraph
 
Reported: 2020-02-11 17:07 UTC by Martin Renvoize
Modified: 2020-08-16 23:49 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Text to go in the release notes:
Version(s) released in:


Attachments
Koha Plugin Signatures (256 bytes, application/octet-stream)
2020-04-30 12:29 UTC, David Cook
Details
Example Koha Plugin Developer Public Key (451 bytes, text/plain)
2020-04-30 12:29 UTC, David Cook
Details
Bug 24632: Verify Koha plugin signatures against trusted author public keys (24.95 KB, patch)
2020-04-30 12:39 UTC, David Cook
Details | Diff | Splinter Review
Bug 24632: Verify Koha plugin signatures against trusted author public keys (24.98 KB, patch)
2020-04-30 14:02 UTC, ByWater Sandboxes
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2020-02-11 17:07:02 UTC
Plugins are currently simply perl code packed into a zip file.. We should add some form of standardized signing protocol to allow verification and authentication of source code.
Comment 1 Martin Renvoize 2020-04-16 06:45:26 UTC
I'm thinking something akin to Debians recommended practices: https://wiki.debian.org/Creating%20signed%20GitHub%20releases

We could then verify signatures as part of the install process.
Comment 2 David Cook 2020-04-16 07:36:34 UTC Comment hidden (obsolete)
Comment 3 David Cook 2020-04-16 09:30:55 UTC Comment hidden (obsolete)
Comment 4 David Cook 2020-04-16 09:31:57 UTC Comment hidden (obsolete)
Comment 5 David Cook 2020-04-30 03:14:49 UTC
I'm thinking something along these lines:

https://ubuntu.com/tutorials/tutorial-how-to-verify-ubuntu

Verify a metadata file or checksum file using a provider's public key (using one of the modules I've suggested). 

Then verify the plugin using a checksum in the metadata file or in the checksum file.

I'm thinking signing the checksum file is probably the better way to go. 

And if we create a system preference to manage this, we can have it turned off by default (for backwards compatibility), but then more cautious parties (like vendors) can enable it. 

Essentially you'd need to verify a plugin during the installation process. 

--

I have many competing projects during my quarantine time, but I'm going to try and look at this tonight. It really shouldn't be that difficult, and I think it would be a huge benefit for the plugin system and Koha.
Comment 6 David Cook 2020-04-30 07:23:16 UTC Comment hidden (obsolete)
Comment 7 David Cook 2020-04-30 07:35:40 UTC Comment hidden (obsolete)
Comment 8 David Cook 2020-04-30 07:46:02 UTC Comment hidden (obsolete)
Comment 9 David Cook 2020-04-30 08:53:20 UTC Comment hidden (obsolete)
Comment 10 David Cook 2020-04-30 12:29:20 UTC
Created attachment 104030 [details]
Koha Plugin Signatures
Comment 11 David Cook 2020-04-30 12:29:56 UTC
Created attachment 104031 [details]
Example Koha Plugin Developer Public Key
Comment 12 David Cook 2020-04-30 12:39:20 UTC
Created attachment 104032 [details] [review]
Bug 24632: Verify Koha plugin signatures against trusted author public keys

The concept is that Koha plugin authors will sign their plugins using their RSA
private key, and they'll share their public key with Koha users/the public. Koha
users will upload/import these public keys into Koha.

When uploading plugins, Koha users will also be prompted to upload a signature
file, which will be provided by Koha plugin authors.

By default, signature verification will be optional. However, if you enable
the system preference "RequirePluginSignatures", you will only be able to upload
Koha plugins which have been signed by a trusted author (ie an author for whom you
have stored a public key).

This patch adds the plugin_keys table and a web UI to store trusted author public keys,
adds the "RequirePluginSignatures" system preference to secure the upload process, and
updates the plugin upload to verify signatures.

Test Plan:
0) Apply patch
1) Download Example Koha Plugin Developer public key
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104031
2) Download Kitchen Sink plugin signature
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104030
3) Download version 2.1.39 of the Kitchen Sink plugin
https://github.com/bywatersolutions/koha-plugin-kitchen-sink/releases/download/v2.1.39/koha-plugin-kitchen-sink-v2.1.39.kpz
4) Go to /cgi-bin/koha/plugins/plugins-keys.pl
5) Upload "Example Koha Plugin Developer public key" here with any "Name" you want
6) Go to /cgi-bin/koha/plugins/plugins-upload.pl
7) Upload Kitchen Sink plugin
8) Notice it uploaded without a signature.
9) Uninstall Kitchen Sink plugin
10) Go to systme preferences and enable "RequirePluginSignatures"
11) Go to /cgi-bin/koha/plugins/plugins-upload.pl
12) Upload Kitchen Sink plugin
13) Notice an error message saying upload failed
14) Go to /cgi-bin/koha/plugins/plugins-home.pl
15) Observe there is no uploaded plugin
16) Go to /cgi-bin/koha/plugins/plugins-upload.pl
17) Upload Kitchen Sink plugin
18) Upload Kitchen Sink plugin signature
19) Notice the plugin uploaded

Advanced Test Plan:
Instead of downloading the Koha Sink plugin signature and public key,
try creating your own keys and signature. The below is just a quick example,
and not necessarily the recommended process. Consider a larger key size.
1) openssl genrsa -des3 -out private.pem 2048
2) openssl rsa -in private.pem -outform PEM -pubout -out public.pem
3) openssl dgst -sha256 -sign private.pem -out koha-plugin-kitchen-sink-v2.1.39.sig koha-plugin-kitchen-sink-v2.1.39.kpz
4) Repeat normal test plan from step 4
Comment 13 ByWater Sandboxes 2020-04-30 14:02:59 UTC
Created attachment 104035 [details] [review]
Bug 24632: Verify Koha plugin signatures against trusted author public keys

The concept is that Koha plugin authors will sign their plugins using their RSA
private key, and they'll share their public key with Koha users/the public. Koha
users will upload/import these public keys into Koha.

When uploading plugins, Koha users will also be prompted to upload a signature
file, which will be provided by Koha plugin authors.

By default, signature verification will be optional. However, if you enable
the system preference "RequirePluginSignatures", you will only be able to upload
Koha plugins which have been signed by a trusted author (ie an author for whom you
have stored a public key).

This patch adds the plugin_keys table and a web UI to store trusted author public keys,
adds the "RequirePluginSignatures" system preference to secure the upload process, and
updates the plugin upload to verify signatures.

Test Plan:
0) Apply patch
1) Download Example Koha Plugin Developer public key
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104031
2) Download Kitchen Sink plugin signature
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104030
3) Download version 2.1.39 of the Kitchen Sink plugin
https://github.com/bywatersolutions/koha-plugin-kitchen-sink/releases/download/v2.1.39/koha-plugin-kitchen-sink-v2.1.39.kpz
4) Go to /cgi-bin/koha/plugins/plugins-keys.pl
5) Upload "Example Koha Plugin Developer public key" here with any "Name" you want
6) Go to /cgi-bin/koha/plugins/plugins-upload.pl
7) Upload Kitchen Sink plugin
8) Notice it uploaded without a signature.
9) Uninstall Kitchen Sink plugin
10) Go to systme preferences and enable "RequirePluginSignatures"
11) Go to /cgi-bin/koha/plugins/plugins-upload.pl
12) Upload Kitchen Sink plugin
13) Notice an error message saying upload failed
14) Go to /cgi-bin/koha/plugins/plugins-home.pl
15) Observe there is no uploaded plugin
16) Go to /cgi-bin/koha/plugins/plugins-upload.pl
17) Upload Kitchen Sink plugin
18) Upload Kitchen Sink plugin signature
19) Notice the plugin uploaded

Advanced Test Plan:
Instead of downloading the Koha Sink plugin signature and public key,
try creating your own keys and signature. The below is just a quick example,
and not necessarily the recommended process. Consider a larger key size.
1) openssl genrsa -des3 -out private.pem 2048
2) openssl rsa -in private.pem -outform PEM -pubout -out public.pem
3) openssl dgst -sha256 -sign private.pem -out koha-plugin-kitchen-sink-v2.1.39.sig koha-plugin-kitchen-sink-v2.1.39.kpz
4) Repeat normal test plan from step 4

Signed-off-by: Holly <hc@interleaf.ie>
Comment 14 David Cook 2020-04-30 23:10:36 UTC
I noticed late yesterday that https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23975 allows a person to fetch plugins directly from Github.

I'll have to take a look at that code to see how it relates to what I've done here. I imagine it shouldn't be too difficult, especially if we use a standard naming convention for signature files.
Comment 15 Jonathan Druart 2020-05-01 10:24:53 UTC
You are assuming that an author who is trusted once is trusted for all the plugins they will write. This assumption is wrong IMO.
Comment 16 David Cook 2020-05-03 23:12:44 UTC
(In reply to Jonathan Druart from comment #15)
> You are assuming that an author who is trusted once is trusted for all the
> plugins they will write. This assumption is wrong IMO.

This assumption is the same as the software package managers on Windows and Linux. I think it's a fair and conventional assumption to make.

That being said, I agree with the content of what you're saying, which is why this feature needs to be paired with a whitelist where administrators can define which plugins should be allowed to be installed.

That way administrators specify that only X authentic plugins from Y trusted authors can be installed.

I'm planning to code the whitelist functionality too, but haven't had the time yet. In lieu of it, I think adding a signature system alone is better than the nothing that we have at the moment.
Comment 17 Martin Renvoize 2020-05-04 10:46:29 UTC
(In reply to Jonathan Druart from comment #15)
> You are assuming that an author who is trusted once is trusted for all the
> plugins they will write. This assumption is wrong IMO.

I agree with David here.. this work is to provide a way of verifying the code is written by an author you trust.. not that this particular plugin is correct.  As such, sharing a key is a fair and well-documented route that many systems already use.
Comment 18 Katrin Fischer 2020-08-16 10:00:03 UTC
I've rebased the patches (kohastructure.sql and plugins-home.tt, but there are a lot of QA script fails:

 FAIL	Koha/Plugins/Key.pm
   OK	  critic
   OK	  forbidden patterns
   OK	  git manipulation
   OK	  pod
   FAIL	  pod coverage
		POD coverage was greater before, try perl -MPod::Coverage=PackageName -e666
   OK	  spelling
   OK	  valid

 FAIL	Koha/Plugins/Keys.pm
   OK	  critic
   FAIL	  forbidden patterns
		forbidden pattern: tab char (line 57)
		forbidden pattern: tab char (line 61)
		forbidden pattern: tab char (line 83)
   OK	  git manipulation
   OK	  pod
   FAIL	  pod coverage
		POD is missing for 'verify_plugin'
   OK	  spelling
   OK	  valid

 FAIL	Koha/Schema/Result/PluginKey.pm
   OK	  critic
   OK	  forbidden patterns
   OK	  git manipulation
   OK	  pod
   FAIL	  pod coverage
		POD is missing for koha_object_class
		POD is missing for koha_objects_class
   OK	  spelling
   OK	  valid

 OK	installer/data/mysql/kohastructure.sql
   OK	  boolean_vs_tinyint
   OK	  charset_collate
   OK	  git manipulation
   OK	  tinyint_has_boolean_flag

 OK	installer/data/mysql/sysprefs.sql
   OK	  git manipulation
   OK	  semicolon
   OK	  sysprefs_order

 FAIL	koha-tmpl/intranet-tmpl/prog/en/modules/plugins/plugins-home.tt
   OK	  filters
   FAIL	  forbidden patterns
		forbidden pattern: trailing space char (line 58)
   OK	  git manipulation
   OK	  js_in_body
   OK	  spelling
   OK	  tt_valid
   OK	  valid_template

 FAIL	koha-tmpl/intranet-tmpl/prog/en/modules/plugins/plugins-keys.tt
   FAIL	  filters
		missing_filter at line 68 (                                                    <li><a class="uninstall_plugin" href="/cgi-bin/koha/plugins/plugins-keys.pl?keyid=[% plugin_key.keyid %]&op=Delete"><i class="fa fa-trash fa-fw"></i> Delete</a></li>)
   FAIL	  forbidden patterns
		forbidden pattern: tab char (line 28)
		forbidden pattern: tab char (line 42)
   OK	  git manipulation
   OK	  js_in_body
   OK	  spelling
   OK	  tt_valid
   OK	  valid_template

 OK	koha-tmpl/intranet-tmpl/prog/en/modules/plugins/plugins-upload.tt
   OK	  filters
   OK	  forbidden patterns
   OK	  git manipulation
   OK	  js_in_body
   OK	  spelling
   OK	  tt_valid
   OK	  valid_template

 FAIL	plugins/plugins-keys.pl
   OK	  critic
   FAIL	  forbidden patterns
		forbidden pattern: Script permissions is authnotrequired => 0, it could be correct for an OPAC script if it is was you really want error (bug 24663) (line 42)
   OK	  git manipulation
   OK	  pod
   OK	  spelling
   OK	  valid

Additional notes:

1) The 2 .perl files for database updates [c/sh]ould be combined.
2) Add comment before new table in kohastructure.sql
3) I wonder if the permission for the new page should not be a little stricter. Currently if you can use plugins, you can also access the page. I'd suggest:
manage - Manage plugins ( install / uninstall )
This should then also affect the visibility of the buttons/links to the page from plugin home.
Comment 19 David Cook 2020-08-16 23:49:48 UTC
Thanks for taking the time to look at this one, Katrin. I appreciate it.

I think for now I'm probably going to abandon this work, and focus instead on patches that limit users' ability to install plugins all together. That is, allow only administrators to install plugins, or allow only a pre-approved list of plugin options, or both.

Hopefully my past work can serve as a bit of an example of what could be done in the future. For now, I don't think there will be enough uptake to warrant continuing working on it. 

But thanks again :)