Bug 1308809 - Certificate requests with certmonger doesn't work on SELinux enabled systems
Certificate requests with certmonger doesn't work on SELinux enabled systems
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tog-pegasus (Show other bugs)
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Vitezslav Crhonek
Alois Mahdal
Depends On:
Blocks: 1320077 1380364
  Show dependency treegraph
Reported: 2016-02-16 02:22 EST by Thorsten Scherf
Modified: 2017-08-01 12:45 EDT (History)
3 users (show)

See Also:
Fixed In Version: tog-pegasus-2.14.1-5.el7
Doc Type: Bug Fix
Doc Text:
Cause – user requests certificates for the CIMOM by using certmonger Consequence – the request fails on SELinux enabled systems, because the certmonger service doesn't have access to the Pegasus configuration directory (/etc/Pegasus) which is defined as default place to store SSL certificates Fix – default place for storing SSL certificates has been changed to more convenient directory (/etc/pki/Pegasus) and README.RedHat.SSL documentation file has been updated accordingly Result – certificate request should work as expected on SELinux enabled systems
Story Points: ---
Clone Of:
Last Closed: 2017-08-01 12:45:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (8.75 KB, patch)
2016-03-21 08:14 EDT, Vitezslav Crhonek
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1969 normal SHIPPED_LIVE tog-pegasus bug fix update 2017-08-01 13:57:01 EDT

  None (edit)
Description Thorsten Scherf 2016-02-16 02:22:08 EST
Description of problem:
In the RHEL7 Administration Guide we describe how people can requests certificates for the CIMOM by using certmonger:

# ipa-getcert request -f /etc/Pegasus/server.pem -k /etc/Pegasus/file.pem -N CN=hostname -K CIMOM/hostname


This doesn't work on SELinux enabled systems, because the certmonger service (running in certmonger_t) doesn't have access to the Pegasus configuration folder (pegasus_conf_t) which is defined as default place to store SSL certificates. See /usr/share/doc/tog-pegasus/README.RedHat.SSL for hardcoded SSL related seetings.

This is the first AVC deny I get when running getcert as described in the documentation:

# ausearch -m AVC -c certmonger
time->Mon Feb 15 11:09:19 2016
type=AVC msg=audit(1455552559.959:264): avc:  denied  { getattr } for  pid=3208 comm="certmonger" path="/etc/Pegasus" dev="dm-0" ino=101728256 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:pegasus_conf_t:s0 tclass=dir permissive=0

I propose to change the hardcoded SSL seetings to store certificate underneath /etc/pki/. That's the place where all certs should be stored. 

I've filed a related documentation BZ:

Version-Release number of selected component (if applicable):
The issue is version not related to a specific version. I applies to all OpenPegasus versions we ship in RHEL/Fedora. 

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 1 Vitezslav Crhonek 2016-03-21 08:14 EDT
Created attachment 1138569 [details]
proposed patch

The patch changes hardcoded paths, updates scripts involved in generating of SSL certificates and /usr/share/doc/tog-pegasus/README.RedHat.SSL. Slightly tested with certmonger example above on RHEL7 and seems to work fine. Already built in Fedora Rawhide for further testing.

Note that we will also need to do minor change in sblim-wbemcli package, because the path to Pegasus's certificates is also hardcoded there. Updating just tog-pegasus would e.g. break existing scripts with wbemcli calls - connections to CIMOM through https without '-noverify' flag. It would make sense to do it simultaneously.
Comment 8 Alois Mahdal 2017-06-26 00:04:21 EDT
Spec file and patches reviewed, regression suite (also sblim-cmpi, which uses Pegasus a lot) re-run and passed.
Comment 9 errata-xmlrpc 2017-08-01 12:45:38 EDT
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.


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