[UBUNTU 23.04] opencryptoki 3.20.0: strength.conf has wrong mode

[bugproxy]

SRU Justification:
==================

[Impact ]

 * Opencryptoki added policy support (after 3.17) with 3.18,
   which requires to have a strength.conf file in place.

 * Without a strength.conf file in place
   and without the correct file permissions of 640,
   such newer opencryptoki versions will not work.

 * Opencryptoki tools have internal code to check for
   correct file permissions.

 * An error like this is shown, in case pkcsconf is going to be used:
   # pkcsconf -t
   Error initializing the PKCS11 library: 0x5 (CKR_GENERAL_ERROR)

[ Test Plan ]

 * A end to end scenario, that covers the following stack:

      Java program using crypto
                   |
                  JCA (with IBM Java 8)
                   |
             IBMPKCS11Impl
                   |
              OpenCryptoki
               / \
          ICA-token soft-token ...
               |
    s390x_clear-key_crypto-hw

   can be based on a Java application that does
   AES encryption in ECB mode with a randomly generated key (DRBG-SHA-512)
   and exploiting JCA / IBMPKCS11Impl
   with opencryptoki managing clear keys,
   either with a soft-token or an ICA token.

 * The pkcsconf tool is here used to manage (initialize and re-label)
   the tokens before used by the Java application.

 * For the detailed steps and the Java application itself,
   please see https://launchpadlibrarian.net/673367325/example.txt

[ Where problems could occur ]

 * The strength.conf file might have wrong content

 * or is located at a wrong position in the file-system

 * or strength.conf might have wrong file permissions,
   which is checked inside of the tool's code.

 * In both cases pkcsconf will still not work even if the file is in place.

[ Other Info ]

 * The strength.conf file allows users to configure openCryptoki
   cryptographic key strength determination based on key attributes.
   And this file is required by openCryptoki.
   The strength configuration file has to be owned by 'root:@pkcs_group',
   have mode 0640, and be parsable. Otherwise, openCryptoki will return
   'CKR_FUNCTION_FAILED' on 'C_Initialize' and log a corresponding message
   to syslog detailing the reason why the strength configuration could
   not be used. (more see 'strength.conf' in man5)

 * The file permissions were set by intention in d/opencryptoki.postinst
   since ownership of strength.conf is set there, too (as well as further
   folder and config file owner and permission changes).
   So all this is at the same place now.

 * Package opencryptoki has reverse dependencies:
   $ reverse-depends -a source src:opencryptoki
   Reverse-Build-Depends
   * simple-tpm-pk11 (for libopencryptoki-dev)
   * tpm-tools (for libopencryptoki-dev)
   These were rebuild for test purposes, in addition to opencryptoki itself,
   and are available at PPA:
   https://launchpad.net/~fheimes/+archive/ubuntu/lp2018911
__________

After installing opencryptoki 3.20.0 on Ubuntu 23.04 the strength.conf file that is installed into /etc/opencryptoki/ has a wrong mode.

After starting pkcsslotrd, command 'pkcsconf -t' shows
     pkcsconf: Error initializing the PKCS11 library: 0x5 (CKR_GENERAL_ERROR)
and the syslog shows:
     usr/lib/api/policy.c POLICY: Configuration file /etc/opencryptoki/strength.conf has wrong permissions!

# ls -l /etc/opencryptoki/strength.conf
-rw-r--r-- 1 root pkcs11 866 Feb 13 09:10 /etc/opencryptoki/strength.conf

So it has a mode of 644, but it must have a mode of 640 ! This is checked by the code, and opencryptoki is not usable if the mode is wrong. The owner "root:pkcs11" is correct.

Circumvention: manually change the mode to 0640. After that 'pkcsconf -t' works.

Note: This affects all architectures where opencryptoki is supported.

[Frank Heimes (fheimes)]

I can confirm that strength.conf is taken as is and installed with default 644.

File permissions will be enforced in post-install script...

[Launchpad Janitor (janitor)]

This bug was fixed in the package opencryptoki - 3.20.0+dfsg-0ubuntu2

---------------
opencryptoki (3.20.0+dfsg-0ubuntu2) mantic; urgency=medium

  * d/rules, d/triggers, d/libopencryptoki0.install: keep tmp/etc/ld.so.conf.d
    content, add opencryptoki conf file to /etc/ld.so.conf.d/
    and add trigger for ldconfig to allow tools like
    p11sak to find libopencryptoki shared object file. (LP: #2022088)
  * d/control, d/compat: Bump dh compat level to 13 to remove dh-exec
    dependency and remove executable flags from d/*.install*, d/*.links*.
  * d/rules: remove the explicit dh_missing call, and rely instead on dh
    to call it and erroring out on missing files.
  * d/opencryptoki.install: install entire content of etc/opencryptoki build
    folder to esp. catch all existing conf files and on top make the arch-
    specific file 'opencryptoki.install.s390x' obsolete. (LP: #2018911)
  * d/opencryptoki.postinst: change strength.conf file permissions to 640
    which is checked/forced by the code. (LP: #2018908)

 -- Frank Heimes <email address hidden> Wed, 31 May 2023 21:28:48 +0200

[Robie Basak (racb)]

Please could you describe the actual end-to-end user story that is blocked by this bug, and then update the Test Plan so that when the bug is fixed it demonstrates the entire user story working? Right now we've got a technical explanation of the problem, but nothing that explains the impact of the bug on users. For that we need a story, and to judge the suitability of this fix for SRU, I need to understand that story.

[Robie Basak (racb)]

And the same question applies to the other two bugs linked from this SRU upload please.

To expand, I do understand that CKR_GENERAL_ERROR is a problem. But what are you actually trying to achieve? That is what needs to be described, and what the Test Plan needs to test.

[Frank Heimes (fheimes)]

@racb Thanks for having a look at this (actually these) opencryptoki bugs.

I've now expanded the SRU Justification and (hopefully) provided more background information, like
where is it used for and why using the tools that are described, and expanded the test cases with
further optional tests.

However, it is difficult to create a larger user story for that, since it would probably be a bit artificial, since opencryptoki is a generic tool to handle crypto tokens - so I would call it an 'infrastructure' for handling crypto tokens.
So there are more or less endless application scenarios and use cases on top of it.
And at the end a user notices that one (or more) of the tools are not working.
A trivial user story is however to for example list existing token info (or create and remove token/keys).
Well, I stuck to that in the description, if you don't mind.

[Frank Heimes (fheimes)]

On top I'll ask the bug reporter about his use case that may fit to an end-2-end user story.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2023-06-12 02:34 EDT-------
I don't quite understand the question about the "end-to-end user story".

This bug simply causes the openCryptoki package to not be usable at all!
Any application that wants to use openCryptoki as its PKCS#11 crypto service implementation will fail.

So the user-story falls back to 'why would one want to use opencryptoki?', right ?
Do we really need a story for that ?

If you want to learn what opencryptoki is for, then please check the manual (https://www.ibm.com/docs/en/linux-on-systems?topic=11-version-317) or the readme file on Github (https://github.com/opencryptoki/opencryptoki/blob/master/README.md)

[Robie Basak (racb)]

> So there are more or less endless application scenarios and use cases on top of it.

OK, so could you please pick a single scenario that does something end-to-end that a user might want, and then adapt the Test Plan to do that please?

"Create a token" or "list tokens" is only part of the story - that isn't useful to a user by itself. In any real world use, the story will extend beyond that point. They will do that in order to achieve some bigger thing, and I'd like for the Test Plan to actually verify that the bigger thing works.

The reason I want this is that if the bigger thing needs further fixes, then I want them to all land at once. I want to avoid landing one change, and then finding out later that it was insufficient for a bigger story and some other change is also needed so we need another SRU. It is not good for users to receive one fix at a time. So we should be testing the complete user story is fixed, not that some technical change is implemented.

It is fine that there are other scenarios that will also be fixed by this. We don't need to cover everything. Just one plausible end-to-end story will do.

> Any application that wants to use openCryptoki as its PKCS#11 crypto service implementation will fail.

So pick one application and one end-to-end use case that will be fixed by this, and use that to demonstrate that the fix is also correct end-to-end please.

> So the user-story falls back to 'why would one want to use opencryptoki?', right ?

Sure, but we can choose something narrower than that for our purposes. I'm not asking for all possible user stories to be implemented. But I am asking for one entire scenario to be tested.

> Do we really need a story for that ?

Yes - to ensure that we are fully testing at least one scenario of what the user actually needs, to ensure that the fix is correct and we don't iterate on fixes in a stable release.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2023-06-15 10:10 EDT-------
One end-to-end use case could be this one: https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-libp11-engine

However, it involves some other packages as well, and they must all play together to make the whole thing work.

The other thing is that this use case meant for OpenSSL 1.1.1, but 23.04 has OpenSSL 3.0. It should still work, but engines are deprecated with OpenSSL 3.0.... Unfortunately there is no provider-based replacement for the libp11 engine so far (we are working on that tough...).

Nevertheless, feel free to adopt that use case for your testing.

[Robie Basak (racb)]

> However, it involves some other packages as well, and they must all play together to make the whole thing work.

That's fine. Ideally the story would use packages entirely from the archive. But it's fine if not, provided that what the archive is providing to users in the test plan is a reasonable use case for Ubuntu as a whole.

This SRU is blocked on the Test Plan being updated as discussed.

[Frank Heimes (fheimes)]

(Sorry, I'm just back for an extended weekend.)

Since there was the change from openssl 1.1 to 3, but the test plan should work in both cases,
I'm better going with an old example (I already wanted to update) from this 16.04 based paper:
https://people.canonical.com/~fheimes/MG_HWCrypto_with_Ubuntu_on_z.pdf (chapter 6.4, 6.4.3 and 6.4.4)

It uses as well a larger set of packages (libica-utils libica4 openssl-ibmca opencryptoki) from the archives, but IBM Java 8 on top.

The stack/scenario is like this:

   Java program using crypto
                |
               JCA (with IBM Java 8)
                |
          IBMPKCS11Impl
                |
           OpenCryptoki
            / \
       ICA-token soft-token ...
            |
 s390x_clear-key_crypto-hw

I just ran the entire test case on 23.04 and have the detailed commands in this attached text file.

I'll add a summary of it to the Bug description / SRU Justification above and will reference for the details to this attached doc.

[Steve Langasek (vorlon)]

Hello bugproxy, or anyone else affected,

Accepted opencryptoki into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/opencryptoki/3.20.0+dfsg-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Frank Heimes (fheimes)]

The updated opencryptoki package for lunar (currently in -proposed) was successfully verified - see attachment.
Hence I'm adjusting the tag accordingly.

[Launchpad Janitor (janitor)]

This bug was fixed in the package opencryptoki - 3.20.0+dfsg-0ubuntu1.1

---------------
opencryptoki (3.20.0+dfsg-0ubuntu1.1) lunar; urgency=medium

  * Add d/p/lp-2022088-fix-p11sak-failure-to-find-libopencryptoki.so.patch
    to fix the failure that p11sak is not able to find libopencryptoki as
    plugin, by adjusting 'default_pkcs11lib'. (LP: #2022088)
  * d/opencryptoki.install: install full set of etc/opencryptoki build
    folder to esp. catch all generated conf files and on top make the arch-
    specific file 'opencryptoki.install.s390x' obsolete. (LP: #2018911)
  * d/opencryptoki.postinst: change strength.conf file permissions to 640
    which is checked/forced by the opencryptoki code. (LP: #2018908)

 -- Frank Heimes <email address hidden> Mon, 12 Jun 2023 12:28:36 +0200

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for opencryptoki has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Steve Langasek (vorlon)]

Hello bugproxy, or anyone else affected,

Accepted opencryptoki into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/opencryptoki/3.18.0+dfsg-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Frank Heimes (fheimes)]

opencryptoki/3.18.0+dfsg-0ubuntu2.1 from kinetic-proposed was successfully verified (see atachment)

updating the tags accordingly...

[Steve Langasek (vorlon)]

An upload of opencryptoki to jammy-proposed has been rejected from the upload queue for the following reason: "to be reuploaded with fixed debian/libopencryptoki0.links file".

[Launchpad Janitor (janitor)]

This bug was fixed in the package opencryptoki - 3.18.0+dfsg-0ubuntu2.1

---------------
opencryptoki (3.18.0+dfsg-0ubuntu2.1) kinetic; urgency=medium

  * Add d/p/lp-2022088-fix-p11sak-failure-to-find-libopencryptoki.so.patch
    to fix the failure that p11sak is not able to find libopencryptoki as
    plugin, by adjusting 'default_pkcs11lib'. (LP: #2022088)
  * d/opencryptoki.install: install full set of etc/opencryptoki build
    folder to esp. catch all generated conf files and on top make the arch-
    specific file 'opencryptoki.install.s390x' obsolete. (LP: #2018911)
  * d/opencryptoki.postinst: change strength.conf file permissions to 640
    which is checked/forced by the opencryptoki code. (LP: #2018908)

 -- Frank Heimes <email address hidden> Thu, 29 Jun 2023 09:39:27 +0200

[Steve Langasek (vorlon)]

Hello bugproxy, or anyone else affected,

Accepted opencryptoki into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/opencryptoki/3.17.0+dfsg+20220202.b40982e-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Frank Heimes (fheimes)]

The opencryptoki/3.17.0+dfsg+20220202.b40982e-0ubuntu1.2 package from jammy-proposed was successfully verified (see atachment).

updating the tags accordingly...

[Launchpad Janitor (janitor)]

This bug was fixed in the package opencryptoki - 3.17.0+dfsg+20220202.b40982e-0ubuntu1.2

---------------
opencryptoki (3.17.0+dfsg+20220202.b40982e-0ubuntu1.2) jammy; urgency=medium

  * Add d/p/lp-2022088-fix-p11sak-failure-to-find-libopencryptoki.so.patch
    to fix the failure that p11sak is not able to find libopencryptoki as
    plugin, by adjusting 'default_pkcs11lib'. (LP: #2022088)
  * d/opencryptoki.install: install full set of etc/opencryptoki build
    folder to esp. catch all generated conf files and on top make the arch-
    specific file 'opencryptoki.install.s390x' obsolete. (LP: #2018911)
  * d/libopencryptoki0.links{.s390x} Merge files, since the content of the
    s390x version of this file applies in all cases,
    and remove leading slash in path for consistency reasons.
  * Assign pkcs11 group to p11sak_defined_attrs.conf and strength.conf
    in debian/opencryptoki.postinst rather than in Makefile.am and add
    d/p/lp-1982842-move-pkcs11-group-assigment-from-makefile-to-postinst.patch
    to solve "invalid group ‘pkcs11’" issues during build.
  * d/opencryptoki.postinst: change strength.conf file permissions to 640
    which is checked/forced by the opencryptoki code. (LP: #2018908)

 -- Frank Heimes <email address hidden> Fri, 30 Jun 2023 10:11:32 +0200