Bug 976308 - FreeIPA's httpd cannot read CRL generated by PKI
FreeIPA's httpd cannot read CRL generated by PKI
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks: 979379
  Show dependency treegraph
 
Reported: 2013-06-20 06:54 EDT by Martin Kosek
Modified: 2013-07-03 20:56 EDT (History)
5 users (show)

See Also:
Fixed In Version: selinux-policy-3.12.1-57.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-03 20:56:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Kosek 2013-06-20 06:54:01 EDT
Description of problem:
FreeIPA Identity Management solution configures PKI/Dogtag to store CRL files in IPA-owned directory /var/lib/ipa/pki-ca/publish/ which is then mapped to one httpd address so that clients can download the CRL and validate a certificate:

# openssl x509 -text -in /tmp/1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 12 (0xc)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=IDM.LAB.BOS.REDHAT.COM, CN=Certificate Authority
...
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
                CRL Issuer:
                  DirName: O = ipaca, CN = Certificate Authority


# ls -laZ /var/lib/ipa/pki-ca/publish/
drwxrwxr-x. root pkiuser system_u:object_r:var_lib_t:s0   .
drwxr-xr-x. root root    system_u:object_r:var_lib_t:s0   ..
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130619-161132.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130619-170000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130619-210000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130620-010000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130620-050000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130620-090000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130620-130000.der
-rw-r--r--. root root    system_u:object_r:pki_tomcat_var_lib_t:s0 MasterCRL-20130620-170000.der


Historically, there used be our custom SELinux subpackage which added a policy to mark this directory with cert_t label and then allowed httpd to read this label. However, this directory was dropped as we use system SELinux policy only.


But, the CRL can now be no longer retrieved:

# wget http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
--2013-06-20 18:39:14--  http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving ipa-ca.idm.lab.bos.redhat.com (ipa-ca.idm.lab.bos.redhat.com)... 10.16.78.119
Connecting to ipa-ca.idm.lab.bos.redhat.com (ipa-ca.idm.lab.bos.redhat.com)|10.16.78.119|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://vm-119.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin [following]
--2013-06-20 18:39:14--  http://vm-119.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving vm-119.idm.lab.bos.redhat.com (vm-119.idm.lab.bos.redhat.com)... 10.16.78.119
Reusing existing connection to ipa-ca.idm.lab.bos.redhat.com:80.
HTTP request sent, awaiting response... 403 Forbidden
2013-06-20 18:39:14 ERROR 403: Forbidden.


There are AVCs for it:

type=AVC msg=audit(1371767954.125:6303): avc:  denied  { read } for  pid=26620 comm="httpd"             name="MasterCRL.bin" dev="dm-0" ino=5037 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:       object_r:pki_tomcat_var_lib_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1371767954.125:6303): arch=c000003e syscall=4 success=no exit=-13                a0=7fa99bcb2e58 a1=7fffade05420 a2=7fffade05420 a3=7fa9907c73b9 items=0 ppid=26616 pid=26620            auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 ses=4294967295          tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1371767954.125:6304): avc:  denied  { getattr } for  pid=26620 comm="httpd" path="/  var/lib/ipa/pki-ca/publish/MasterCRL.bin" dev="dm-0" ino=5037 scontext=system_u:system_r:httpd_t:s0     tcontext=system_u:object_r:pki_tomcat_var_lib_t:s0 tclass=lnk_file


To make it working, I had to manually run restorecon on the directory so that the files get more general "var_lib_t" label which is readable by httpd:

# restorecon -FvvR /var/lib/ipa/pki-ca/publish/
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130619-210000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130619-161132.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-050000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL.bin context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-170000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-130000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-090000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-010000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0
restorecon reset /var/lib/ipa/pki-ca/publish/MasterCRL-20130619-170000.der context system_u:object_r:pki_tomcat_var_lib_t:s0->system_u:object_r:var_lib_t:s0


# wget http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
--2013-06-20 18:41:56--  http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving ipa-ca.idm.lab.bos.redhat.com (ipa-ca.idm.lab.bos.redhat.com)... 10.16.78.119
Connecting to ipa-ca.idm.lab.bos.redhat.com (ipa-ca.idm.lab.bos.redhat.com)|10.16.78.119|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://vm-119.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin [following]
--2013-06-20 18:41:56--  http://vm-119.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving vm-119.idm.lab.bos.redhat.com (vm-119.idm.lab.bos.redhat.com)... 10.16.78.119
Reusing existing connection to ipa-ca.idm.lab.bos.redhat.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 414 [application/octet-stream]
Saving to: ‘MasterCRL.bin’

100%[==============================================================>] 414         --.-K/s   in 0s      

2013-06-20 18:41:56 (59.2 MB/s) - ‘MasterCRL.bin’ saved [414/414]


Should this be fixed in selinux-policy-targeted by defining a custom label for the /var/lib/ipa/pki-ca/publish/ or somehow by fixing dogtag to run restorecon each time it uploads a new CRL file so that the files do not have label "pki_tomcat_var_lib_t"?


Version-Release number of selected component (if applicable):
selinux-policy-3.12.1-47.fc19.noarch

How reproducible:
Only reproducible with development builds of FreeIPA 3.3 package which has the dropped selinux subpackage.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Miroslav Grepl 2013-06-20 07:39:53 EDT
# rpm -qf /var/lib/ipa/pki-ca/publish
freeipa-server-3.2.1-1.fc19.x86_64

# matchpathcon /var/lib/ipa/pki-ca/publish	
system_u:object_r:cert_t:s0

So I guess we should label it as cert_t in the policy. If you execute

# chcon -R -t cert_t /var/lib/ipa/pki-ca/publish

does it work then?
Comment 2 Martin Kosek 2013-06-20 08:15:20 EDT
Yes, that fixes the issue:

# chcon -R -t cert_t /var/lib/ipa/pki-ca/publish
# ls -laZ /var/lib/ipa/pki-ca/publish/
drwxrwxr-x. root pkiuser system_u:object_r:cert_t:s0      .
drwxr-xr-x. root root    system_u:object_r:var_lib_t:s0   ..
-rw-r--r--. root root    system_u:object_r:cert_t:s0      MasterCRL-20130619-161132.der
...
lrwxrwxrwx. root root    system_u:object_r:cert_t:s0      MasterCRL.bin -> /var/lib/ipa/pki-ca/publish/MasterCRL-20130620-170000.der

# wget http://ipa-ca.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
...
HTTP request sent, awaiting response... 200 OK
Length: 414 [application/octet-stream]
Saving to: ‘MasterCRL.bin’
...

If httpd is allowed by default to read cert_t , then I think this would be a good solution.
Comment 3 Miroslav Grepl 2013-06-20 09:13:45 EDT
Well but if you have freeipa-server installed

# rpm -qf /var/lib/ipa/pki-ca/publish
freeipa-server-3.2.1-1.fc19.x86_64

you should get the correct labeling then.

Installing:
 freeipa-server                  x86_64          3.2.1-1.fc19          fedora          1.1 M
Installing for dependencies:
 freeipa-server-selinux          x86_64          3.2.1-1.fc19          fedora           43 k
Comment 4 Martin Kosek 2013-06-20 09:24:04 EDT
Yup, but as I mentioned in the beginning, freeipa-server-selinux is exactly the SELinux package that we are dropping in 3.3.

This single labeling rule seems to be the only SELinux rule that is missing in the system policy...
Comment 5 Miroslav Grepl 2013-06-20 09:40:21 EDT
Ah, I missed it.
Comment 8 Miroslav Grepl 2013-06-21 10:23:00 EDT
commit 97c040a126f3ee409f60e70c6653e13c0111d096
Author: Miroslav Grepl <mgrepl@redhat.com>
Date:   Fri Jun 21 16:21:36 2013 +0200

    Add label cert_t for /var/lib/ipa/pki-ca/publish
Comment 10 Fedora Update System 2013-06-26 16:19:32 EDT
selinux-policy-3.12.1-57.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-57.fc19
Comment 11 Martin Kosek 2013-06-27 03:56:33 EDT
This looks good, I tested it with devel build of FreeIPA 3.3 and it worked OK.

Just one (general) question Mirek - is it a problem SELinux-wise if /var/lib/ipa/pki-ca/publish does not exist always on the system, but only after IPA server+CA is installed (with ipa-server-install)? The directory label seems to be applied right, but I just wanted to be sure.
Comment 12 Martin Kosek 2013-06-27 04:15:13 EDT
Ah, it seems I just found one more related issue when testing selinux-policy-3.12.1-57.fc19.noarch - SELinux do not allow pki-ca to write to this cert_t-labeled directory:

type=AVC msg=audit(1372363810.078:7970): avc:  denied  { write } for  pid=23292 comm="java"             name="publish" dev="dm-0" ino=1685 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:    object_r:cert_t:s0 tclass=dir

This leads to following error in /var/log/pki/pki-tomcat/ca/system:
23226.CRLIssuingPoint-MasterCRL - [27/Jun/2013:16:10:10 EDT] [20] [3] FileBasedPublisher: java.io.      FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20130627-161009.temp (Permission denied)

Mirek, do you this could be allowed in the policy?
Comment 13 Fedora Update System 2013-06-27 11:50:00 EDT
Package selinux-policy-3.12.1-57.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-57.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
then log in and leave karma (feedback).
Comment 14 Martin Kosek 2013-06-28 07:23:25 EDT
I rather filed a new bug for tracking the second issue - Bug 979379.

It is true that it is quite different problem than the one in this Bugzilla + this one is already owned by bodhi.
Comment 15 Fedora Update System 2013-07-03 20:56:08 EDT
selinux-policy-3.12.1-57.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.