1 - Installed and configured nethsm 2000 today. [ enquiry report attached ] 2 - Right off the bat SELinux prevented me from using the install wizard to login. Apr 9 16:16:15 gamma setroubleshoot: SELinux is preventing the java (pki_ca_t) from executing /opt/nfast/toolkits/pkcs11/libcknfast.so. For complete SELinux messages. run sealert -l ffca174e-5582-47a1-b10d-6f23b3e9f263 at this point I set "setenforce 0" to put selinux in permissive mode and finished the CA config wizard. Everything went ok except I couldn't login to the agent page. I noticed this error: Secure Connection Failed An error occurred during a connection to gamma.dsdev.sjc.redhat.com:9443. SSL peer reports incorrect Message Authentication Code. (Error code: ssl_error_bad_mac_alert)
some more selinux messages that I saw along the way wrt hsm.. Apr 9 16:16:15 gamma setroubleshoot: SELinux is preventing the java (pki_ca_t) from executing /opt/nfast/toolkits/pkcs11/libcknfast.so. For complete SELinux messages. run sealert -l ffca174e-5582-47a1-b10d-6f23b3e9f263 Apr 9 16:16:15 gamma setroubleshoot: SELinux is preventing java (pki_ca_t) "write" to nserver (device_t). For complete SELinux messages. run sealert -l 51fa9aea-b1b0-464d-a89f-7804f9b76b0b Apr 9 16:19:20 gamma setroubleshoot: SELinux is preventing java (pki_ca_t) "write" to ./local (usr_t). For complete SELinux messages. run sealert -l 6b258d51-dd92-4cac-bd34-bbd76522c652 Apr 9 16:19:20 gamma setroubleshoot: SELinux is preventing java (pki_ca_t) "write" to /opt/nfast/kmdata/local/key_pkcs11_uc69b9d052b9027c934f6301689d6c94583b790601-82fba4fa5169eca7b2ce47d40f38447fc6926c57.new (usr_t). For complete SELinux messages. run sealert -l abb0faa0-3c5d-4ab3-8d9a-d9abaf51cd23 Apr 9 16:19:20 gamma setroubleshoot: SELinux is preventing java (pki_ca_t) "remove_name" to ./key_pkcs11_uc69b9d052b9027c934f6301689d6c94583b790601-82fba4fa5169eca7b2ce47d40f38447fc6926c57.new (usr_t). For complete SELinux messages. run sealert -l 201fe2dc-ac76-48f9-a25f-741066a4449b Apr 9 16:19:20 gamma setroubleshoot: SELinux is preventing java (pki_ca_t) "unlink" to ./key_pkcs11_uc69b9d052b9027c934f6301689d6c94583b790601-82fba4fa5169eca7b2ce47d40f38447fc6926c57 (usr_t). For complete SELinux messages. run sealert -l 76807b79-1d54-4fe5-89e3-65cbeb605a21
It's been reported that without SELinux turned to permissive, with HSM attached, the Done panel's url disply was incorrect, and that was the reason of the bad_record_mac_ssl. A workaround is to manually type in the correct url. It needs to be investigated though why the presence of the hsm would cause the url to be incorrectly displayed.
I"m asking Matt to file a separate bug for what seems like port separation related issue. It's less severe when there is a workaround, but it's still better to be fixed.
I added two comments to the other bug that may be useful in debugging the bad_mac problem. https://bugzilla.redhat.com/show_bug.cgi?id=495597#c1 https://bugzilla.redhat.com/show_bug.cgi?id=495597#c2
Created attachment 342149 [details] patch (initial for testing) Initial checkin for testing purposes. This should get most of it.
builder@oliver base]$ svn ci -m "Bugzilla Bug 495157: SELinux prevents CA from using nethsm pkcs11 module" selinux Sending selinux/src/pki.fc Sending selinux/src/pki.if Sending selinux/src/pki.te Transmitting file data ... Committed revision 423. [builder@oliver base]$ cd .. [builder@oliver pki]$ cd dogtag/ [builder@oliver dogtag]$ svn ci -m "Bugzilla Bug 495157: SELinux prevents CA from using nethsm pkcs11 module" selinux Sending selinux/pki-selinux.spec Transmitting file data . Committed revision 424. Leaving this in assigned mode for now ..
Ade, I saw some more. [root@zeta ~]# cat /var/log/audit/audit.log | audit2allow #============= pki_ca_t ============== allow pki_ca_t device_t:sock_file write; allow pki_ca_t unconfined_t:unix_stream_socket connectto; allow pki_ca_t usr_t:dir { write remove_name add_name }; allow pki_ca_t usr_t:file { write rename execute unlink create }; #============= pki_kra_t ============== allow pki_kra_t device_t:sock_file write; allow pki_kra_t self:process signal; allow pki_kra_t unconfined_t:unix_stream_socket connectto; allow pki_kra_t usr_t:dir { write remove_name add_name }; allow pki_kra_t usr_t:file { write rename execute unlink create }; #============= pki_ocsp_t ============== allow pki_ocsp_t device_t:sock_file write; allow pki_ocsp_t unconfined_t:unix_stream_socket connectto; allow pki_ocsp_t usr_t:file execute; #============= pki_ra_t ============== allow pki_ra_t device_t:sock_file write; #============= pki_tks_t ============== allow pki_tks_t device_t:sock_file write; allow pki_tks_t unconfined_t:unix_stream_socket connectto; allow pki_tks_t usr_t:dir { write remove_name add_name }; allow pki_tks_t usr_t:file { write rename execute unlink create }; #============= pki_tps_t ============== allow pki_tps_t device_t:sock_file write; allow pki_tps_t unconfined_t:unix_stream_socket connectto; allow pki_tps_t usr_t:dir { write remove_name add_name }; allow pki_tps_t usr_t:file { write rename create unlink };
this one was on machine all subsystems configured using nethsm.
chandra, Were these messages on the system before you installed the build or afterwards? Did you null out the audit log PRIOR to doing the install?
after. this was with yday's build.
Created attachment 345360 [details] patch to fix the problem is that ncipher does not have its own selinux policy. so rather than add nasty rules to our policy, we created an selinux context for the ncipher bits. dwalsh does this all the time. One problem is that for some reason, the context for the files under /dev/nfast are not set without doing an explicit restorecon. We could do this through an explicit udev rule - but as the context is defined by our app - lets just set it when we start up our app. So, we add a couple of lines to the startup scripts for the case where we have lunasa. mharmsen, please review.
chandra -- once the above patch is checked in, note the following: 1. you should be able to do everything with selinux enabled. (but test once with permissive). 2. on a new system, you will need to restart the hsm client process after the pki-selinux policy is installed and before doing the CA etc. configuration. This needs to be documented somewhere. This is because the hsm process needs to be restarted within the correct selinux context.
attachment (id=345360) +mharmsen CAVEATS: * - Comment #12 refers to "lunasa", but your changes only appear to be for the nCipher "netHSM"; do we need something similar to support Safenet's "lunasa"? * - Please update all 6 spec files under pki/dogtag
the comment #12 is incorrect -- it should say nethsm. no additional is required for lunasa. [builder@dhcp231-124 dogtag]$ svn ci -m "Bugzilla Bug #495157 - SELinux prevents CA from using nethsm pkcs11 module" Sending dogtag/ca/pki-ca.spec Sending dogtag/kra/pki-kra.spec Sending dogtag/ocsp/pki-ocsp.spec Sending dogtag/ra/pki-ra.spec Sending dogtag/tks/pki-tks.spec Sending dogtag/tps/pki-tps.spec Transmitting file data ...... Committed revision 491.
[builder@dhcp231-124 pki]$ svn ci -m "Bugzilla Bug #495157 - SELinux prevents CA from using nethsm pkcs11 module" base/ca/shared/etc/init.d/httpd base/tks/shared/etc/init.d/httpd base/ra/etc/init.d/httpd base/ocsp/shared/etc/init.d/httpd base/tps/etc/init.d/httpd base/kra/shared/etc/init.d/httpd Sending base/ca/shared/etc/init.d/httpd Sending base/kra/shared/etc/init.d/httpd Sending base/ocsp/shared/etc/init.d/httpd Sending base/ra/etc/init.d/httpd Sending base/tks/shared/etc/init.d/httpd Sending base/tps/etc/init.d/httpd Transmitting file data ...... Committed revision 492.
Ade - I'm still seeing a bunch of messages in my audit.log. I have re-installed my sub-systems as of june 04. Can you take a look and tell me if these are ok ?
Created attachment 346749 [details] selinux audit files
chandra -- Its likely that you will see a bunch of messages if the hsm client was running prior to your install. The real test is as follows: 1. put selinux in enforcing mode 2. clear out your audit log 3. install the rpms 4. restart the hsm client process 5. configure the subsystems and confirm that they work. If all works, then the initial selinux messages can be ignored.
chandra, Another way, you could try this is as follows: From a clean system: 1. stop the hsm client. 2. clear out the audit logs 3. yum install pki-selinux 4. restart the hsm client 5. install and configure the pki subsystems. You could do this in permissive mode -- ideally, there should be no selinux messages in your audit log.
verified with 06/16. no messages on audit.log for ca/nethsm. looks clean.