Per CS/DS Meeting 09/25/2017: 10.5 blocker

Closing this one. If we feel we need to add more, will create a new one later.

jmagne wrote:

commit 1467340ef3c0a7aede4e264aff93bb6a7e7eb6ee
Author: Jack Magne <jmagne>
Date:   Wed Oct 18 10:18:37 2017 -0700

    Fix #2735 Secure removal of secret data storage.
    
    https://pagure.io/dogtagpki/issue/2735
    
    This phase provides a method to clear memory using a configurable method, ei
    
    The configuration for this is:
    
    jss.obscureMethod=random
    or
    jss.obscureMethod=zeroes
    
    This fix consists of a new method in JssSubsystem and examples of the callin
    
    The next phase will consist of the rest of the servers that do this kind of 
    
    Also: I had to  fix  drmtest.py to complete the test run. The problem is whe
    
    Fixed confusing comment in the obscureBytes method.
    
    Change-Id: I276e3a9b678cb6b34b6c6b6a78ba2968b84f74d8


Testing instructions for phase one of this where, we work on the most crucial kra first:

Testing instructions:

With this fix, we have decided to clear security data only in the kra, to act as a proof of concept.

To test the integrity of this fix, we want to make sure that the kra still functions normally and that the log messages created when we clear memory are showing up when expected. The following is what can be done at this point to test this all out.

    Stand up a kra along with a CA.

    Configure the kra to allow encryption and decryption when archiving and recovering keys. This is because the fix lies in this area heavily:

kra.allowEncDecrypt.recovery=true
kra.allowEncDecrypt.archival=true

We can also configure the desired obscuring method, with "zeroes" being the default:

jss.obscureMethod=random
or
jss.obscureMethod=zeroes

    Restart the kra:

    We want to run the test program called "drmtest.py", because this exercises the SecurityData / rest functionality we have added to the kra. This functionality archives and recovers things like sym keys, asym keys, and passphrases or security strings.

    The test program is located in a source tree here:

pki/base/kra/functional/drmtest.py

Help to run this test is located in a text file in the same area:

pki/base/kra/functional/drmtest.readme.txt

This file will show how to configure and run the test.

    Run drmtest.py and observer that all the tests succeed. This can be observed by simply watching the output in the console. Note that there are several tests that are designed to fail, so make sure that continues.

    After running the drmtest, look in the kra debug log to make sure there are places where the function to clear memory is being called.

    Finally, in order to test general legacy kra functionality, preform the usual standard / legacy key archival and recovery testing procedures and make sure everything works and that the logs reflect the memory being cleared out.



Subsequent checkin: This handles some more byte array cases:

commit f5ec7c2af4a1fb44d5731c74672bf789e9240499 (HEAD -> master, origin/master, origin/HEAD, obscure-memory)
Author: Jack Magne jmagne
Date: Tue Nov 7 11:05:55 2017 -0800

Fix #2735 Secure removal of secret data storage (phase 2)

This portion of the fix attempts to take care of the remaining secret data
storage issues that could be practically taken care of with respect to
servers and clients.

A new method was placed in CryptoUtil to server the needs of clients.
Change-Id: I1a14daabcad72e531572d1be8bc255e2e501b70a

We still need to address the many String based password type cases.



commit daff3951340246d97a9877d5dde4782c8c675974
Author: Jack Magne <jmagne>
Date:   Fri Nov 10 10:57:36 2017 -0800

    Fix #2735 Secure removal of secret data storage (phase 3)
    
    Add more secure data removal with respect to passwords.
    Concentrate on the CMC Shared Token area. Done by changing
    String based passwords to char[] based password, which then can be cleaned.
    Cleaned up a couple of minor review suggestions.
    
    Change-Id: I898814000353978f403f19f679083474548edc5e




Testing instructions for phase 2 and 3:

We added 2 more phases of the checkins to this bug.

Once again, we made some changes to try to secure some more memory data and password data.

The changes are not server wide but we wanted to cover some more important sections of the code. Those sections being all the new CMC client and server code and some more changes to the KRA to support password data cleanup. As for passwords, the framework code for cleaning all passwords has been put in place and exercised in the CMS and KRA area. The following are the areas to test for correctness and sanity. There is no way QE can actually tell if the data is being obscured correctly, but we want to make sure we have not broken anything .Therefore the following tests would be useful:

    Test all of the new CC CMC client and server code, with emphasis on the new SHARED TOKEN pathway. The code had to be moved a bit to support cleaning the passoword, thus we want to make sure the shared token authentication still works, and to perform sanity on the rest of the CMC functionality of interest to CC.

    Re-test all the kra stuff talked about in phase 1. This is because we added some password functionality to the KRA security data archival and recovery routines.

    Make sure configuration works along with pk#12 processing. There were some minor changes to some of the code that creates and processes pk#12 files. This is where sanity should suffice, since I"m sure all this stuff is tested anyway.

    A small bit of TKS /TMS code was enhanced for security data removal. Just observe that the standard TMS stuff still works as usual.

Note:

Some but not all of the server changes will have messages placed in the debug logs, indicating that a piece of data is being obscured or clean. Simple inspection of some of that can at least show the idea that this kind of thing is going on. Not all will be recorded since some of the cleaning is taking place in client code.

Created attachment 1377373 [details]
phase 1 test results

I have performed tests for phase 1 (please refer attachment for drmtest.py output) also legacy KRA functionality is working as expected.

Seeing the issue in comment 11 using the latest copr builds pki-ca-10.5.1-5.1.el7.noarch, so marking this bug to ASSIGNED.

[root@nocp1 alias]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.5.1
Release     : 7.el7
Architecture: noarch
Install Date: Tue 06 Feb 2018 03:09:43 PM EST
Group       : System Environment/Daemons
Size        : 2359899
License     : GPLv2
Signature   : (none)
Source RPM  : pki-core-10.5.1-7.el7.src.rpm
Build Date  : Tue 06 Feb 2018 02:04:51 AM EST
Build Host  : ppc-035.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority

All the tests described in comment 5 were successfully executed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0925