Bug 1027265 - Certmonger man pages need a note about SELinux
Certmonger man pages need a note about SELinux
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: certmonger (Show other bugs)
6.5
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Nalin Dahyabhai
Kaleem
: Documentation
Depends On:
Blocks: 1061410
  Show dependency treegraph
 
Reported: 2013-11-06 07:55 EST by Dmitri Pal
Modified: 2014-10-14 03:12 EDT (History)
7 users (show)

See Also:
Fixed In Version: certmonger-0.75.3-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-14 03:12:31 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 Dmitri Pal 2013-11-06 07:55:05 EST
People are trying to create certs using certmonger in the directories that SELinux does not allow access by default.
Certmonger man pages should be updated to explain what needs to be done to enable certmonger to create these files.

There might be other certmonger operations that can cause AVC. We should document how to overcome those too.
Comment 1 Dmitri Pal 2013-11-06 07:57:58 EST
Related thread and reply from Alexander.
https://www.redhat.com/archives/freeipa-users/2013-November/msg00040.html

IMO his reply can be a foundation for the man page change.
Comment 2 Rob Crittenden 2013-11-06 08:43:59 EST
Probably worth mentioning the existence of /etc/pki/tls/certs and and /etc/pki/tls/private for cert/key storage on Fedora/RHEL systems. I don't know what the equivalent is on Debian-based distros.
Comment 3 Arthur 2013-11-07 09:42:53 EST
I think that Rob Crittenden solution is the best! I have checked it out, everything works fine!
So there should be just a note in documentation with recommendations to store keys and certificates here.
here is my example:

# ipa-getcert request -f /etc/pki/tls/certs/postgresql.crt
-k /etc/pki/tls/private/postgresql.key -K
postgresql/postgresql.example.com -N CN=postgresql.example.com -D
postgresql.example.com

# ipa-getcert list
Request ID '20131107050729':
	status: MONITORING
	stuck: no
	key pair storage:
type=FILE,location='/etc/pki/tls/private/postgresql.key'
	certificate: type=FILE,location='/etc/pki/tls/certs/postgresql.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=EXAMPLE.COM
	subject: CN=postgresql.example.com,O=EXAMPLE.COM
	expires: 2015-11-08 05:07:29 UTC
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

after I've changed owner:
# chown postgres /etc/pki/tls/certs/postgresql.crt
# chown postgres /etc/pki/tls/private/postgresql.key
# ll /etc/pki/tls/certs/postgresql.crt 
-rw-------. 1 postgres root 1318 Ноя  7
11:07 /etc/pki/tls/certs/postgresql.crt
# ll /etc/pki/tls/private/postgresql.key 
-rw-------. 1 postgres root 1704 Ноя  7
11:07 /etc/pki/tls/private/postgresql.key

it seems to be starting well!
Comment 5 Nalin Dahyabhai 2014-06-18 16:27:57 EDT
We should have 'see also' pointers to the (somewhat dry) certmonger_selinux(8) page in all of the section 1 and 8 man pages now, and the getcert-request(1) and getcert-start-tracking(1) man pages also now include:

NOTES
       Locations specified for key and certificate storage need to be accessi‐
       ble to the certmonger daemon process.  When run as a system daemon on a
       system which uses a mandatory access control mechanism such as SELinux,
       the system policy must ensure that the daemon is allowed to access the
       locations where certificates and keys that it will manage will be
       stored (these locations are typically labeled as cert_t or an equiva‐
       lent).  More SELinux-specific information can be found in the
       selinux.txt documentation file for this package.

The referenced selinux.txt reads:

I'm running SELinux.  What is certmonger allowed to access?

If your copy of certmonger runs confined, you can read the label which
should be applied to its binary file with:

  # matchpathcon /usr/sbin/certmonger
  /usr/sbin/certmonger	system_u:object_r:certmonger_exec_t:s0

Meanwhile, you can read the label which is currently applied to its
binary file with:

  # ls --scontext /usr/sbin/certmonger 
  system_u:object_r:certmonger_exec_t:s0 /usr/sbin/certmonger

If the results differ, use "restorecon" to reset the label of the
file to value that your configuration says it should have:

  # restorecon /usr/sbin/certmonger 

You can query which domain the process will be run in, when the binary
is started by the init system, with:

  # sesearch -T -t certmonger_exec_t
  Found 2 semantic te rules:
     type_transition init_t certmonger_exec_t : process certmonger_t;
     type_transition initrc_t certmonger_exec_t : process certmonger_t;

You can then query which types and attributes (loosely, groups of type)
of directories a process running as "certmonger_t" will be allowed to
create files in, and what sorts of files it will be able to create and
write to:

  # sesearch --allow -s certmonger_t -c dir -p add_name
     allow certmonger_t cert_type : dir { ioctl read write getattr lock add_name remove_name search open } ;
     allow certmonger_t certmonger_var_lib_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
     allow certmonger_t certmonger_var_run_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
     ...

  # sesearch --allow -s certmonger_t -c file -p create,write
     allow certmonger_t cert_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     allow certmonger_t certmonger_t : file { ioctl read write getattr lock append open } ;
     allow certmonger_t certmonger_var_lib_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     allow certmonger_t certmonger_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     ...

By convention, type names end with "_t", but attribute names don't.
Attribute names can be resolved to the list of types to which they're
applied with:

  # seinfo -x --attribute=cert_type
     cert_type
        pki_tomcat_cert_t
        dovecot_cert_t
        home_cert_t
        cert_t
        slapd_cert_t

Each of those types, in turn, will be applied to one or more files or
directories by default when packages are installed, when the system was
installed, or when the "restorecon" command is used to relabel files and
directories.  To obtain a list of which path patterns are configured to
receive a particular type, you can use a command :

  # semanage fcontext -l | grep :cert_t:
  /etc/httpd/alias(/.*)?               all files system_u:object_r:cert_t:s0
  /etc/pki(/.*)?                       all files system_u:object_r:cert_t:s0
  /etc/ssl(/.*)?                       all files system_u:object_r:cert_t:s0
  /usr/share/ca-certificates(/.*)?     all files system_u:object_r:cert_t:s0
  /usr/share/pki/ca-certificates(/.*)? all files system_u:object_r:cert_t:s0
  /usr/share/pki/ca-trust-source(/.*)? all files system_u:object_r:cert_t:s0
  /usr/share/ssl/certs(/.*)?           all files system_u:object_r:cert_t:s0
  /usr/share/ssl/private(/.*)?         all files system_u:object_r:cert_t:s0
  /var/named/chroot/etc/pki(/.*)?      all files system_u:object_r:cert_t:s0

In enforcing mode, locations which fit these patterns are the locations
which the certmonger daemon will be allowed to read and write.

Feedback welcome.
Comment 7 Kaleem 2014-08-07 08:20:34 EDT
There are couple of observations from my side.

(1)Man page for certmonger_selinux(8) is missing.
(2)An example in file selinux.txt will be helpful.
   like mkdir /tmp/certs ; chcon -t cert_t /tmp/certs
Comment 8 Kaleem 2014-08-20 10:38:59 EDT
Verified.

certmonger_selinux man page provided by selinux-policy-doc pkg.

certmonger_selinux pointers exits in getcert* and certmonger* man pages.
Comment 9 errata-xmlrpc 2014-10-14 03:12:31 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.

http://rhn.redhat.com/errata/RHBA-2014-1512.html

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