Hide Forgot
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.
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.
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.
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!
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.
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
Verified. certmonger_selinux man page provided by selinux-policy-doc pkg. certmonger_selinux pointers exits in getcert* and certmonger* man pages.
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