Bug 1630361

Summary: PKINIT fails in FIPS mode
Product: Red Hat Enterprise Linux 7 Reporter: Florence Blanc-Renaud <frenaud>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: cpelland, mkosek, ndehadra, nsoman, pvoborni, rcritten, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.6.4-10.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 11:00:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Florence Blanc-Renaud 2018-09-18 13:02:16 UTC
This bug is created as a clone of upstream ticket:
https://pagure.io/freeipa/issue/7594

### Issue
CIS hardened images with FIPS 140-2 enabled do not allow Fresh install of FreeIPA 4.5 to work.

#### Steps to Reproduce

This is less about steps to reproduce, and more about what I needed to do to make freeIPA work on a FIPS 140-2 and CIS-1 2.2.0 level harden

The default umask for the following files is too restrictive and causes kinit -n to fail

~~~~
[root@example ]# kinit -n
Password for WELLKNOWN/ANONYMOUS.COM:
~~~~

Kinit was asking for a password instead of trusing the certs

These files in a CIS image are root:root 600, they need to be root:root 644
~~~~
/var/lib/ipa-client/pki/ca-bundle.pem
/etc/pki/ca-trust/source/ipa.p11-kit
~~~~
Once the permissions are fixed, you can kinit -n 

The web server fails to allow you to log in because the permissions are too restrictive on /etc/httpd/alias, the permissions shuold be 755 but CIS changes them to 600

Checking the error logs, the only detail that was returned was this

~~~~
ipa: INFO: 401 Unauthorized: [Errno 13] Permission denied
~~~~

I straced all the apache pids to determine the real error
~~~~
ps auxw | grep -E 'sbin/(apache|httpd)' | awk '{print"-p " $2}' | xargs strace -e trace=write -F -s 100000000
~~~~
When entering the username/password the following segfault is returned.
~~~~
[pid 23361] write(2, "[Thu Jun 21 18:00:54.930103 2018] [:error] [pid 23361] Unable to change directory to /etc/httpd/alias\n", 102) = 102
[pid 23361] write(2, "[Thu Jun 21 18:00:54.930307 2018] [:error] [pid 23361] Does the directory exist and do the permissions allow access?\n", 117) = 117
[pid 23361] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x28} ---
~~~~
Once the permissions were solved on  /etc/httpd/alias there were still issues, the ipaapi proxy was still returning problems.  

The httpd logs still said 
~~~~
ipa: INFO: 401 Unauthorized: [Errno 13] Permission denied
~~~~
but there were no more segfaults or problems, i traced the ipaapi process 

~~~~
ps auxw | grep -E 'ipaapi' | awk '{print"-p " $2}' | xargs strace -e trace=open -F -s 100000000
~~~~

after tracing the ipaapi proxy i found that /etc/ipa/ca.crt were also too restrictive (600), they shuold be 644

~~~~
[pid 25624] open("/etc/ipa/ca.crt", O_RDONLY) = -1 EACCES (Permission denied)
~~~~
After changing the permissions to 644 everything works.

In summary the following changes needed to be made to make FreeIPA work on a CIS hardened machine.
~~~~
chmod 644 /var/lib/ipa-client/pki/ca-bundle.pem
chmod 644 /etc/pki/ca-trust/source/ipa.p11-kit
chmod 755 /etc/httpd/alias/
chmod 644 /etc/ipa/ca.crt
~~~~
#### Actual behavior
kinit -n does not work, and unable to log into the web UI

#### Expected behavior
FreeIPA works with CIS restrictive umask settings

#### Version/Release/Distribution
   $ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.5.4-10.el7.centos.1.x86_64
ipa-client-4.5.4-10.el7.centos.1.x86_64
389-ds-base-1.3.7.5-21.el7_5.x86_64
pki-ca-10.5.1-9.el7.noarch
krb5-server-1.15.1-19.el7.x86_64


#### Additional info:
Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.

~~~~

logs available in pagure ticket

Comment 2 Florence Blanc-Renaud 2018-09-18 13:04:32 UTC
Fixed upstream
master:

    ba8cbb8 Ensure that public cert and CA bundle are readable
    1434f2a Always make ipa.p11-kit world-readable
    89b2137 Make /etc/httpd/alias world readable & executable
    c2eb0f1 Fix permission of public files in upgrader

ipa-4-6:

    fc63ad8 Ensure that public cert and CA bundle are readable
    9576e3c Always make ipa.p11-kit world-readable
    b76b50d Make /etc/httpd/alias world readable & executable
    8164fba Fix permission of public files in upgrader

Comment 3 Martin Kosek 2018-09-18 13:10:42 UTC
I fixed the title to match the issue being solved here.

As for the umask errors, I assume those rather resolved rather in Bug 1485217.

Comment 5 Nikhil Dehadrai 2018-09-20 12:44:48 UTC
Version:
pki-server-10.5.9-6.el7.noarch
ipa-server-4.6.4-10.el7.x86_64


Verified the bug on the basis of following steps:
1. Setup RHEL 7.6 system in FIPS mode.
2. run command 'umask 077' on this system.
3. Install IPA server in FIPS mode.
4. Check file perfissions related with ipa
5. Check IPA UI login
6. run command 'kinit -n'


Result:
---------
1. After step3, ipa-server installation is successful
2. File permissions are setup correctly.
3. Login to ipa-server UI successful
4. 'kinit -n' command is successful


Console:
=====================


Before install:
---------------
[root@vm-idm-022 ~]# rpm -q ipa-server
ipa-server-4.6.4-10.el7.x86_64
[root@vm-idm-022 ~]# umask 077
[root@vm-idm-022 ~]# ipa-server-install


After install:
-------------
[root@vm-idm-022 ~]# tail -1 /var/log/ipaserver-install.log 
2018-09-20T12:12:11Z INFO The ipa-server-install command was successful

[root@vm-idm-022 ~]# ls -l /var/lib/ipa-client/pki/ca-bundle.pem
-rw-r--r--. 1 root root 1298 Sep 20 17:41 /var/lib/ipa-client/pki/ca-bundle.pem

[root@vm-idm-022 ~]# ls -l /etc/pki/ca-trust/source/ipa.p11-kit
-rw-r--r--. 1 root root 2505 Sep 20 17:41 /etc/pki/ca-trust/source/ipa.p11-kit

[root@vm-idm-022 ~]# ls -ld /etc/httpd/alias/
drwxr-x---. 2 root apache 198 Sep 20 17:39 /etc/httpd/alias/

[root@vm-idm-022 ~]# ls -l /etc/ipa/ca.crt
-rw-r--r--. 1 root root 1298 Sep 20 17:37 /etc/ipa/ca.crt

[root@vm-idm-022 ~]# rpm -q ipa-server
ipa-server-4.6.4-10.el7.x86_64

[root@vm-idm-022 ~]# cat /proc/sys/crypto/fips_enabled
1

[root@vm-idm-022 ~]# Login UI successful


[root@vm-idm-022 ~]# kinit -n
[root@vm-idm-022 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_nRruePb
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS

Valid starting       Expires              Service principal
09/20/2018 17:48:25  09/21/2018 17:48:24  krbtgt/TESTRELM.TEST
[root@vm-idm-022 ~]#


Also, verified the same on Replica system with similar results.

Thus on the basis of above observations marking the status of bug to 'VERIFIED'

Comment 7 errata-xmlrpc 2018-10-30 11:00:22 UTC
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:3187