Bug 1117673

I'm encountering this issue too on Fedora 20 when removing a CA instance with pkidestroy, then attempting to reinstall it again with pkispawn (using local Dogtag 10.2 builds).  I see the following AVC messages in Permissive mode:

---------------------------------------------------------------------------
type=AVC msg=audit(1409006586.502:568): avc:  denied  { setfscreate } for  pid=52631 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process
type=AVC msg=audit(1409006586.502:569): avc:  denied  { create } for  pid=52631 comm="cp" name="CS.cfg.bak.20140825154306" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file
type=AVC msg=audit(1409006586.502:570): avc:  denied  { relabelfrom } for  pid=52631 comm="cp" name="CS.cfg.bak.20140825154306" dev="dm-1" ino=657333 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file
type=AVC msg=audit(1409006586.502:570): avc:  denied  { relabelto } for  pid=52631 comm="cp" name="CS.cfg.bak.20140825154306" dev="dm-1" ino=657333 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file
type=AVC msg=audit(1409006586.502:571): avc:  denied  { create } for  pid=52632 comm="ln" name="CS.cfg.bak" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file
type=AVC msg=audit(1409006586.503:572): avc:  denied  { read } for  pid=52445 comm="pkidaemon" name="CS.cfg.bak" dev="dm-1" ino=657337 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file
---------------------------------------------------------------------------

Is there an ETA on addressing this in selinux-policy?

It would be fixed by restorecon context for /var/lib/pki-ca/ in a scriptlet.

Could you run before an update

# restorecon -R -v /var/lib/pki-ca/

update and see if there is an issue. 

And I will need to add some additional rules.

mgrepl - I think you might be confused.  The path is /var/lib/pki/pki-tomcat

I updates selinux-policy to version selinux-policy-3.12.1-182.fc20.noarch

I still get the following AVC:

require {
	type pki_tomcat_etc_rw_t;
	type pki_tomcat_t;
	class process setfscreate;
	class lnk_file { read getattr };
	class file relabelfrom;
}

#============= pki_tomcat_t ==============
allow pki_tomcat_t pki_tomcat_etc_rw_t:file relabelfrom;
allow pki_tomcat_t pki_tomcat_etc_rw_t:lnk_file { read getattr };
allow pki_tomcat_t self:process setfscreate;

And my server does not restart.

To be clear, I updated to the specified selinux policy version and ran restorecon -Fr /var/lib/pki 

My server still did not work.

(In reply to Ade Lee from comment #6)
> To be clear, I updated to the specified selinux policy version and ran
> restorecon -Fr /var/lib/pki 
> 
> My server still did not work.

Ok and how does your labeling look? And could you attach raw AVC msgs?

Created attachment 934441 [details]
audit log

lrwxrwxrwx. pkiuser pkiuser system_u:object_r:pki_tomcat_etc_rw_t:s0 /var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak -> /var/lib/pki/pki-tomcat/conf/ca/archives/CS.cfg.bak.20140902132844

-rw-rw----. pkiuser pkiuser system_u:object_r:pki_tomcat_etc_rw_t:s0 CS.cfg.bak.20140903171437

drwxr-xr-x. pkiuser pkiuser system_u:object_r:pki_tomcat_etc_rw_t:s0 /var/lib/pki/pki-tomcat/conf/ca/archives/

What does

$ matchpathcon /var/lib/pki/pki-tomcat

$ ls -dZ /var/lib/pki/pki-tomcat

for you? And again what is your output of

# restorecon -Rv /var/lib/pki

I can respond to that for my system:

[root@vm-040 ~]# matchpathcon /var/lib/pki/pki-tomcat
/var/lib/pki/pki-tomcat	system_u:object_r:pki_tomcat_var_lib_t:s0
[root@vm-040 ~]# ls -dZ /var/lib/pki/pki-tomcat
drwxrwx---. pkiuser pkiuser system_u:object_r:pki_tomcat_var_lib_t:s0 /var/lib/pki/pki-tomcat
[root@vm-040 ~]# restorecon -Rv /var/lib/pki
(no output)

So it works on your system. This is still mislabeling issue.

Miroslav, the output on my system was identical to that in Ade's comment.

Created attachment 940746 [details]
AVC log messages after a successful pkispawn

Created attachment 940749 [details]
/var/log/audit/audit.log with selinux-policy-3.12.1-183.fc20.noarch and enforcing

Using selinux-policy-3.12.1-183.fc20.noarch with enforcing enabled, seeing AVC failures after a successful pkispawn. "AVC log messages after a successful pkispawn" attachment has the AVC log messages and "/var/log/audit/audit.log with selinux-policy-3.12.1-183.fc20.noarch and enforcing" has the audit log.

We're seeing selinux errors related to this on f21.

# ausearch -m AVC -ts today
> ----
> time->Thu Sep 25 11:15:37 2014
> type=AVC msg=audit(1411636537.716:129): avc:  denied  { create } for  pid=22513
> comm="cp" name="CS.cfg.bak.20140925111537"
> scontext=system_u:system_r:pki_tomcat_t:s0
> tcontext=unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file permissive=0
> 
> 

[root@vm-182 ~]# rpm -q selinux-policy
selinux-policy-3.13.1-82.fc21.noarch

[root@vm-182 ~]# audit2allow  -i /var/log/audit/audit.log 


#============= pki_tomcat_t ==============

#!!!! This avc is a constraint violation.  You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule: 
	constrain file { create relabelfrom relabelto } ((u1 == u2 -Fail-)  or (t1 == can_change_object_identity -Fail-) ); Constraint DENIED

#	Possible cause is the source user (system_u) and target user (unconfined_u) are different.
allow pki_tomcat_t pki_tomcat_etc_rw_t:file create;

Tested out a local policy on f21 as suggested by mgrepl:

policy_module(mypol,1.0)

require{
 type pki_tomcat_t;
}

domain_obj_id_change_exemption(pki_tomcat_t)

# save the above to mypol.te
# make -f /usr/share/selinux/devel/Makefile mypol.pp
# semodule -i mypol.pp

That policy worked and allowed server to start up with no AVCs.

commit 76a9b1b1288c4ed23a851c2331b95f8235ea805b
Author: Miroslav Grepl <mgrepl>
Date:   Fri Sep 26 09:08:24 2014 +0200

    Allow pki-tomcat to change SELinux object identity.

selinux-policy-3.12.1-188.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-188.fc20

Package selinux-policy-3.12.1-188.fc20:
* should fix your issue,
* was pushed to the Fedora 20 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-188.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11932/selinux-policy-3.12.1-188.fc20
then log in and leave karma (feedback).

Tested with selinux-policy-3.12.1-192.fc20.noarch,

Looks like the issue mentioned in comment #11 is not fixed.

time->Tue Nov  4 08:49:58 2014
type=USER_AVC msg=audit(1415108998.735:69): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=2)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
----
time->Tue Nov  4 08:51:10 2014
type=PROCTITLE msg=audit(1415109070.394:73): proctitle=6370002D61002F7661722F6C69622F706B692F706B692D6D61737465722F636F6E662F63612F43532E636667002F7661722F6C69622F706B692F706B692D6D61737465722F636F6E662F63612F61726368697665732F43532E6366672E62616B2E3230313431313034303835313130
type=SYSCALL msg=audit(1415109070.394:73): arch=c000003e syscall=190 success=yes exit=0 a0=4 a1=7fff037ec050 a2=22798f0 a3=2d items=0 ppid=19354 pid=19542 auid=4294967295 uid=17 gid=17 euid=17 suid=17 fsuid=17 egid=17 sgid=17 fsgid=17 tty=(none) ses=4294967295 comm="cp" exe="/usr/bin/cp" subj=system_u:system_r:pki_tomcat_t:s0 key=(null)
type=AVC msg=audit(1415109070.394:73): avc:  denied  { relabelto } for  pid=19542 comm="cp" name="CS.cfg.bak.20141104085110" dev="dm-1" ino=2753701 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file permissive=1
Fail: AVC messages found.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.