certmonger runs as euid root and egid root with SELinux context system_u:system_r:certmonger_t:s0.

Permissions are:

# stat -c "%U:%G %C %A  %n" /etc/pki/pki-tomcat/ /etc/pki/pki-tomcat/alias/ /etc/pki/pki-tomcat/alias/*
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 drwxrwx---  /etc/pki/pki-tomcat/
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_cert_t:s0 drwxrwx---  /etc/pki/pki-tomcat/alias/
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_cert_t:s0 -rw-------  /etc/pki/pki-tomcat/alias/cert8.db
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_cert_t:s0 -rw-------  /etc/pki/pki-tomcat/alias/key3.db
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_cert_t:s0 -r--------  /etc/pki/pki-tomcat/alias/pwdfile.txt
pkiuser:pkiuser unconfined_u:object_r:pki_tomcat_cert_t:s0 -rw-------  /etc/pki/pki-tomcat/alias/secmod.db


Either certmonger must keep DAC override or we have to change the permissions of Dogtag's cert database. On Fedora 27, certmonger has DAC override capability:

# sesearch -s certmonger_t -c capability -A
allow certmonger_t certmonger_t:capability { chown dac_override dac_read_search kill setgid setuid sys_nice };
# rpm -qa selinux-policy
selinux-policy-3.13.1-283.24.fc27.noarch

Rawhide with latest updates is missing dac_override:

# sesearch -s certmonger_t -c capability -A
allow certmonger_t certmonger_t:capability { chown dac_read_search kill setgid setuid sys_nice };
[root@vm-171-224 cheimes]# rpm -qa selinux-policy
selinux-policy-3.14.1-5.fc28.noarch

DAC override was removed in https://github.com/fedora-selinux/selinux-policy-contrib/commit/cc5d0d7c98d06866f26dd1f54b34f70fd3b531f9#diff-0d26a87f84b9e59489b46abce068d59f

Upstream PR against rawhide: https://github.com/fedora-selinux/selinux-policy-contrib/pull/49

There is also a different way. certmonger is running as root but does not have to these directories with DAC. Therefore it requires such capability.

  sh# rpm -q selinux-policy
  selinux-policy-3.14.1-5.fc28.noarch

  sh# ls -ld /etc/pki/pki-tomcat
  drwxrwx---. 5 pkiuser pkiuser 4096 Feb  6 12:44 /etc/pki/pki-tomcat

Just user pkiuser or group pkiuser have access to such directory based on DAC.
So more secure approach will be to either run certmonger as pkiuser (which is created by dogtag)
or better to change group to root on related directories.

  ls -ld /etc/pki/pki-tomcat
  drwxrwx---. 5 pkiuser root 4096 Feb  6 12:44 /etc/pki/pki-tomcat

So I am not sure whether it should be moved to certmonger, dogtag or freeipa-server chich is responsible for setup of dogtag.

You are suggesting a new feature and not a bug fix. First of all I'm interested to have rawhide working. The commit from comment3 is obviously wrong for certmonger and just needs to be reverted for certmonger.to to go back to the old behavior ASAP.

How about you give both of your proposal a try and report back after you have finished your research? You may want to talk to Dogtag team first and inquire if it is feasible to change file and directory permissions. Any change must *NOT* compromise security for users that run with SELinux disabled.

Running certmonger as pkiuser won't work because it manages certs for many more services beside the fact that dogtag is not required by certmonger

(In reply to Christian Heimes from comment #6)
> You are suggesting a new feature and not a bug fix. First of all I'm
> interested to have rawhide working. The commit from comment3 is obviously
> wrong for certmonger and just needs to be reverted for certmonger.to to go
> back to the old behavior ASAP.
> 

Removing dac_override from selinux policy modules is not a bug it is a feature/
security hardening.

An example from different BZ: autofs maintainer manage to get rid of that capability after changing code. I cannot see any reasonable explanation why it cannot be done with dogtag.

(In reply to Rob Crittenden from comment #7)
> Running certmonger as pkiuser won't work because it manages certs for many
> more services beside the fact that dogtag is not required by certmonger

This is exatly a reason why Comment5 contains 2nd part
"""
or better to change group to root on related directories.

  ls -ld /etc/pki/pki-tomcat
  drwxrwx---. 5 pkiuser root 4096 Feb  6 12:44 /etc/pki/pki-tomcat
"""

(In reply to Christian Heimes from comment #6)
> How about you give both of your proposal a try and report back after you
> have finished your research? You may want to talk to Dogtag team first and
> inquire if it is feasible to change file and directory permissions. Any
> change must *NOT* compromise security for users that run with SELinux
> disabled.

I have only 10 years of experince in IT but I cannot see how could other users compromise dogtag after following change:

From:
  drwxrwx---. 5 pkiuser pkiuser 4096 Feb  6 12:44 /etc/pki/pki-tomcat

To:
  drwxrwx---. 5 pkiuser root 4096 Feb  6 12:44 /etc/pki/pki-tomcat


Would you be so kind and could you explain that? Maybe I missed something.

sh# getent group pkiuser
pkiuser:x:17:

sh# getent passwd pkiuser
pkiuser:x:17:17:Certificate System:/usr/share/pki:/sbin/nologin

Certmonger is a trusted component, if you change permission so that the root group can read those files, now all your work to remove dac override from other daemons is wasted, as they do not need dac override anymore to just go and grab keys.

"you are holding it wrong"

Q.E.D.

Yes, in theory it is possible to drop DAC override capability from certmonger. But that would require a major redesign and complication of certmonger. You'd have to split it into multiple components, each running as target user with yet another SELinux context. It's a tremendous effort for very little security improvements.

Removing dac_override from certmonger is a bug. Period!

Lukas falsely assumed that certmonger does not require dac_override. He couldn't know better, because simple operations don't need dac_override and the requirement was not documented. The bug was caught by Adam during rawhide testing phase and I have submitted a fix. No harm was done. End of story.

(In reply to Simo Sorce from comment #11)
> Certmonger is a trusted component,
What do you mean by trusted component?
Do you mean that it is allowed by selinux-policy to access such files?

sh# sesearch -A -s certmonger_t -t pki_tomcat_etc_rw_t
allow certmonger_t pki_tomcat_etc_rw_t:dir { getattr open search };
sh# sesearch -A -s certmonger_t -t pki_tomcat_cert_t
allow certmonger_t cert_type:dir { add_name getattr ioctl lock open read remove_name search write };
allow certmonger_t cert_type:file { append create getattr ioctl link lock open read rename setattr unlink write };
allow certmonger_t cert_type:lnk_file { append create getattr ioctl link lock read rename setattr unlink write };
allow certmonger_t pki_tomcat_cert_t:dir { add_name getattr ioctl lock open search write };
allow certmonger_t pki_tomcat_cert_t:file { append getattr ioctl lock open read write };
allow certmonger_t pki_tomcat_cert_t:lnk_file { create getattr };


> if you change permission so that the root
> group can read those files, now all your work to remove dac override from
> other daemons is wasted, as they do not need dac override anymore to just go
> and grab keys.
>

In enforcing mode, just certmonger_t, tomcat_t and htpd_t can do something with files in /etc/pki/pki-tomcat

sh[selinux-policy-contrib]$ git grep pki_rw_tomcat_cert
certmonger.te:  pki_rw_tomcat_cert(certmonger_t)
pki.if:interface(`pki_rw_tomcat_cert',`

sh[selinux-policy-contrib]$ git grep pki_manage_tomcat_cert
pki.if:interface(`pki_manage_tomcat_cert',`
tomcat.te:    pki_manage_tomcat_cert(tomcat_t)

sh[selinux-policy-contrib]$git grep pki_read_tomcat_cert
apache.te:      pki_read_tomcat_cert(httpd_t)
pki.if:interface(`pki_read_tomcat_cert',`

So changing group (pkiuser -> root) would not allow other daemons to access such files.


In permissive/disabled mode, other daemons running as a root could access these files even with perms (drwxrwx---. 5 pkiuser pkiuser) because they would not be blocked by selinux due to dac_override.

> "you are holding it wrong"
Maybe, or you did not provide sufficient justification why certmonger should have capability dac_override.

I do not want to say it *MUST NOT* have such capability. There are use-cases where such capability is required. But it seems that I cannot see them.

As Rob and Christian wrote: Just on IPA server certmonger has access to dirsrv NSS database, PKI NSS database, Apache (ipaapi) NSS DB, KDC cert, RA agent cert. Combining ownership of root, dirsrv, pkiuser users. Or root, ipaapi, dirsrv, apache, pkiuser groups.

Other use cases of certmonger on other servers might touch Cert DBs of completely different users. Changing user of certmonger is completely out of scope of this bug.

(In reply to Petr Vobornik from comment #15)
> As Rob and Christian wrote: Just on IPA server certmonger has access to
> dirsrv NSS database, PKI NSS database, Apache (ipaapi) NSS DB, KDC cert, RA
> agent cert. Combining ownership of root, dirsrv, pkiuser users. Or root,
> ipaapi, dirsrv, apache, pkiuser groups.
>

And I proved that from SELinux POV in comment 13.
But without SELinux root can access these files anyway.
 
> Other use cases of certmonger on other servers might touch Cert DBs of
> completely different users. Changing user of certmonger is completely out of
> scope of this bug.

I agree running certmonger as non-privileged user is not solution.
I wrote it just as an example. But I also wrote few times that certmonger
can run as root and you need to just change ownerwhip of directories to get rid of requirements for CAP_DAC_OVERRIDE for certmonger.

I agree that cermonger can also track other certificates then just certificates created for IPA use-case. However, current SELinux policy would not allow to renew certificates which are stored anywhere. Lets check it

certmonger can write(and thus update certificates) to following SELinux file context

  sh# sesearch -A -s certmonger_t -c file -p write | sed -e 's/{.*//'
  allow certmonger_t auth_cache_t:file
  allow certmonger_t cert_type:file
  allow certmonger_t certmonger_t:file
  allow certmonger_t certmonger_tmp_t:file
  allow certmonger_t certmonger_unit_file_t:file
  allow certmonger_t certmonger_var_lib_t:file
  allow certmonger_t certmonger_var_run_t:file
  allow certmonger_t dirsrv_config_t:file
  allow certmonger_t ipa_log_t:file
  allow certmonger_t ipa_var_lib_t:file
  allow certmonger_t ipa_var_run_t:file
  allow certmonger_t krb5_host_rcache_t:file
  allow certmonger_t krb5_keytab_t:file
  allow certmonger_t krb5kdc_conf_t:file
  allow certmonger_t pki_tomcat_cert_t:file
  allow certmonger_t systemd_passwd_var_run_t:file
  allow certmonger_t systemd_unit_file_type:file
  allow daemon cluster_conf_t:file
  allow daemon cluster_tmp_t:file
  allow daemon cluster_var_lib_t:file
  allow daemon cluster_var_run_t:file
  allow daemon initrc_tmp_t:file
  allow daemon puppet_tmp_t:file
  allow daemon root_t:file
  allow daemon user_cron_spool_t:file
  allow domain afs_cache_t:file
  allow domain puppet_tmp_t:file

Nobody woudl store certivicate on non-persistent storage (ramdisk) or in
directories dedicated for log files or cache . After filterring we will get following
SELinux file context

  allow certmonger_t cert_type:file
  allow certmonger_t certmonger_.*
  allow certmonger_t dirsrv_config_t:file
  allow certmonger_t ipa_var_lib_t:file
  allow certmonger_t krb5kdc_conf_t:file
  allow certmonger_t pki_tomcat_cert_t:file
  allow daemon cluster_conf_t:file
  allow daemon cluster_var_lib_t:file
  allow daemon root_t:file

certmonger_.* are of course not a problem becuase they are owned
  by certmonger rpm package and thus rpm

ipa_var_lib_t is also fine because they are owned by root as well
  [root@rawhide ~]# ls -ld /var/lib/ipa
  drwxr-xr-x. 7 root root 86 Feb  7 04:00 /var/lib/ipa
  [root@bkr-hv02-guest01 ~]# ls -ld /var/lib/ipa/*
  drwx------. 2 root root    6 Jan 31 14:49 /var/lib/ipa/backup
  drwx------. 2 root root    6 Jan 31 14:49 /var/lib/ipa/gssproxy
  drwxr-xr-x. 2 root root    6 Jan 31 14:49 /var/lib/ipa/pki-ca
  drwx--x--x. 2 root root 4096 Feb  7 04:02 /var/lib/ipa/sysrestore
  drwx------. 2 root root   30 Feb  7 04:02 /var/lib/ipa/sysupgrade

krb5kdc_conf_t is not problematic because it is owned by root

  [root@rawhide ~]# ls -ld /etc/krb5kdc /sr/var/krb5kdc /var/kerberos/krb5kdc
  ls: cannot access '/etc/krb5kdc': No such file or directory
  ls: cannot access '/usr/var/krb5kdc': No such file or directory
  drwxr-xr-x. 2 root root 39 Feb  7 04:01 /var/kerberos/krb5kdc
  [root@rawhide ~]# ls -l /var/kerberos/krb5kdc
  total 8
  -rw-------. 1 root root  22 Feb  3 11:32 kadm5.acl
  -rw-------. 1 root root 615 Feb  7 04:02 kdc.conf

generic cert_t are also find because they are owned by root:root
  [root@rawhide ~]# find /etc/pki/ -type d -exec ls -ld {} \;
  drwxr-xr-x. 11 root root 192 Feb  7 05:47 /etc/pki/
  drwxr-xr-x. 4 root root 73 Feb  7 03:49 /etc/pki/ca-trust
  drwxr-xr-x. 4 root root 52 Feb  7 03:49 /etc/pki/ca-trust/source
  drwxr-xr-x. 2 root root 6 Jan 22 09:38 /etc/pki/ca-trust/source/anchors
  drwxr-xr-x. 2 root root 6 Jan 22 09:38 /etc/pki/ca-trust/source/blacklist
  drwxr-xr-x. 5 root root 58 Feb  7 03:49 /etc/pki/ca-trust/extracted
  drwxr-xr-x. 2 root root 35 Feb  7 03:49 /etc/pki/ca-trust/extracted/java
  drwxr-xr-x. 2 root root 47 Feb  7 03:49 /etc/pki/ca-trust/extracted/openssl
  drwxr-xr-x. 2 root root 101 Feb  7 03:49 /etc/pki/ca-trust/extracted/pem
  drwxr-xr-x. 2 root root 8192 Feb  7 03:49 /etc/pki/rpm-gpg
  drwxr-xr-x. 2 root root 21 Feb  7 03:49 /etc/pki/java
  drwxr-xr-x. 5 root root 81 Feb  7 03:49 /etc/pki/tls
  drwxr-xr-x. 2 root root 54 Feb  7 03:49 /etc/pki/tls/certs
  drwxr-xr-x. 2 root root 6 Feb  1 12:13 /etc/pki/tls/misc
  drwxr-xr-x. 2 root root 6 Feb  1 12:13 /etc/pki/tls/private
  drwxr-xr-x. 2 root root 103 Feb  7 05:46 /etc/pki/nssdb
  drwx------. 2 root root 6 Jan 11 09:39 /etc/pki/rsyslog
  drwxr-xr-x. 4 root root 61 Feb  7 05:46 /etc/pki/dovecot
  drwxr-xr-x. 2 root root 6 Jan 20 17:54 /etc/pki/dovecot/certs
  drwxr-xr-x. 2 root root 6 Jan 20 17:54 /etc/pki/dovecot/private
  drwxr-xr-x. 2 root root 101 Feb  7 05:47 /etc/pki/fwupd
  drwxr-xr-x. 2 root root 70 Feb  7 05:47 /etc/pki/fwupd-metadata

In the end, the only problematic are dirsrv_config_t and pki_tomcat_cert_t
which are created by ipa-server-install.

  [root@rawhide ~]# namei -mo /etc/dirsrv/slapd-EXAMPLE-TEST/cert9.db
  f: /etc/dirsrv/slapd-EXAMPLE-TEST/cert9.db
   dr-xr-xr-x root   root   /
   drwxr-xr-x root   root   etc
   drwxrwxr-x root   dirsrv dirsrv
   drwxr-x--- dirsrv dirsrv slapd-EXAMPLE-TEST
   -rw-r----- root   root   cert9.db
  [root@rawhide ~]# namei -mo /etc/pki/pki-tomcat/alias/cert8.db
  f: /etc/pki/pki-tomcat/alias/cert8.db
   dr-xr-xr-x root    root    /
   drwxr-xr-x root    root    etc
   drwxr-xr-x root    root    pki
   drwxrwx--- pkiuser pkiuser pki-tomcat
   drwxrwx--- pkiuser pkiuser alias
   -rw------- pkiuser pkiuser cert8.db

I know it is simpler to allow CAP_DAC_OVERRIDE for certmonger then fixing issues in ipa-server-install or related subcomponents.

But then PR https://github.com/fedora-selinux/selinux-policy-contrib/pull/49
should not contain comment that certmonger requires such capability but that
freeIPA requires CAP_DAC_OVERRIDE for certmonger as a workaround for unconsistant  setup of subcomponents.

(In reply to Lukas Slebodnik from comment #17)
> I know it is simpler to allow CAP_DAC_OVERRIDE for certmonger then fixing
> issues in ipa-server-install or related subcomponents.

Lukas, I believe people in this Bugzilla were pretty clear that this is not the place to redesign certmonger or FreeIPA. We need to fix this Beta blocker and do it quick. Thanks to Christian for proactively sending patches!

Hi All, 

At first, I need to say that Lukas S. is mostly right from SELinux POV. We had bug in kernel[1]. After this change, I tried to remove dac_override where it is not needed. So yes, this is security feature not a bug. 

*BUT* if it's really risky to fix it in certmonger code. I have no other chance just to allow it. 

Here is the build with fix[2]. 

[1] http://www.paul-moore.com/blog/d/2017/07/linux_v412.html
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=24838309

Thanks,
Lukas.

(In reply to Martin Kosek from comment #18)
> (In reply to Lukas Slebodnik from comment #17)
> > I know it is simpler to allow CAP_DAC_OVERRIDE for certmonger then fixing
> > issues in ipa-server-install or related subcomponents.
> 
> Lukas, I believe people in this Bugzilla were pretty clear that this is not
> the place to redesign certmonger or FreeIPA. We need to fix this Beta
> blocker and do it quick. Thanks to Christian for proactively sending patches!

According to fedora 28 schedule beta release is on 2018-03-27.
So it would be enough time to modify installer.

And as I wrote in Comment17 I was fine with adding it back as a workaround.
Is there a plan fix it future? Where should it be tracked (BZ, upstream) ?

Lukas,
patches welcome.
If you can provide patches in time I am sure Lukas can set back dac override in the policy. Feel free to open *another* bug and attach patches when ready.

Correct. Given that the certmonger currently behaves as designed (considering Comment 6, Comment 11 and Comment 12), this is not the place where certmonger should be redesigned.

A ticket with redesign ideas (and even patches as Simo mentioned) can be simply filed in upstream project tracker:
https://pagure.io/certmonger
When this proposal is accepted and done upstream, it can be brought to Fedora.

(In reply to Martin Kosek from comment #24)
> Correct. Given that the certmonger currently behaves as designed
> (considering Comment 6, Comment 11 and Comment 12), this is not the place
> where certmonger should be redesigned.
>

All these tickets are invalid from SELinux POV.

Because certmonger itself does not require CAP_DAC_OVERRIDE. It is required
just in setup done by freeIPA. More details in Comment 16.

(In reply to Simo Sorce from comment #23)
> Lukas,
> patches welcome.
> If you can provide patches in time I am sure Lukas can set back dac override
> in the policy.

it seems that you admit here that the bug is neither in selinux-policy nor in certmonger. 

> Feel free to open *another* bug and attach patches when ready.

I have nicer and cooler projects when I plan to contribute so it will have very low priority on my TODO list. But I'll open *another* bug to track it somewhere.

Simo,

thank you very much for your time and for your replies.

Thanks for following up in a new ticket.

Just to quickly comment on Comment 16, I think you are basing it on wrong assumptions:

(In reply to Lukas Slebodnik from comment #16)
...
> I agree that cermonger can also track other certificates then just
> certificates created for IPA use-case. However, current SELinux policy would
> not allow to renew certificates which are stored anywhere. Lets check it
...

Note that projects or applications can have own SELinux module that then allow certmonger writing to it's certificate stores.

(In reply to Martin Kosek from comment #27)
> Just to quickly comment on Comment 16, I think you are basing it on wrong
> assumptions:
>

Or your assumption is wrong that other application with custom SELinux policy can require anything. Somebody can decide to store certs in /var/db/shadow.cert (fcontext shadow_t) but it does not mean that it should be allowed for certmonger_t to modify files with fcontext shadow_t.

> (In reply to Lukas Slebodnik from comment #16)
> ...
> > I agree that certmonger can also track other certificates then just
> > certificates created for IPA use-case. However, current SELinux policy would
> > not allow to renew certificates which are stored anywhere. Lets check it
> ...
> 
> Note that projects or applications can have own SELinux module that then
> allow certmonger writing to it's certificate stores.

Projects or applications should follow best practices and do not require unnecessary requirements from other project.

And as it was already mentioned (6 times) that there is simple way how to solve it. Owner of directory/file can be anything and group will be root. And ideally store them under standard directory (/etc/pki) and not some random place with totally unrelated SELinux file context dirsrv_config_t ...

Ok. Thanks for your comments!

As I do not see a value in having further technical discussion in this Bugzilla, as noted couple times, I will stop commenting here - I think this dead horse was beaten enough.

(In reply to Martin Kosek from comment #29)
> Ok. Thanks for your comments!
> 
> As I do not see a value in having further technical discussion in this
> Bugzilla, as noted couple times, I will stop commenting here - I think this
> dead horse was beaten enough.

Thank you very for your non-technical comments.

I will create fedora BZ because I did not get direct answer for question in Comment 20