Description of problem: SELinux AVC denials for pki found in Fedora 18. Version-Release number of selected component (if applicable): selinux-policy-3.11.1-82.fc18.noarch How reproducible: Steps to Reproduce: Following AVC denials shows up during pki subsystem installation: time->Mon Mar 4 16:10:59 2013 type=SYSCALL msg=audit(1362431459.125:385): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=7fa800006ff0 a2=90800 a3=0 items=0 ppid=9760 pid=9778 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java" subj=system_u:system_r:pki_tomcat_t:s0 key=(null) type=AVC msg=audit(1362431459.125:385): avc: denied { read } for pid=9778 comm="java" name="hsperfdata_root" dev="tmpfs" ino=24346 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir ---- time->Mon Mar 4 16:10:59 2013 type=SYSCALL msg=audit(1362431459.125:386): arch=c000003e syscall=2 success=no exit=-13 a0=7fa800007010 a1=242 a2=180 a3=0 items=0 ppid=9760 pid=9778 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java" subj=system_u:system_r:pki_tomcat_t:s0 key=(null) type=AVC msg=audit(1362431459.125:386): avc: denied { write } for pid=9778 comm="java" name="hsperfdata_root" dev="tmpfs" ino=24346 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir Actual results: Expected results: Additional info:
hsperfdata_root seems to be mislabeled. Where is this directory located? on /tmp?
Did you actually see anything break?
(In reply to comment #2) > Did you actually see anything break? I'm fairly certain things continue to work fine with Dogtag despite this AVC. Asha can correct me if I'm wrong, but this issue is occuring in a QE Beaker environment. Perhaps there is something related to this Beaker environment that is causing hsperfdata_root to be mislabeled.
It looks like hsperfdata_root is something created by Java (not sure exactly what triggers the creation). The label suggests that it is being created when java is executed as part of a scriptlet in a spec file (one of the Dogtag spec files?). Perhaps we need to somehow automatically relabel this file as plain tmp_t by calling restorecon on it in %post? Us pki_tomcat_t allowed to write to a tmp_t dir?
Yes the directory is being created in the post install, which is why it is created as rpm_script_tmp_t. Not sure why this is created in a /tmp dir, probably should be created in /var/run or /var/lib.
(In reply to comment #5) > Yes the directory is being created in the post install, which is why it is > created as rpm_script_tmp_t. Not sure why this is created in a /tmp dir, > probably should be created in /var/run or /var/lib. I don't think that there is control over the location. The JVM creates this directory itself. It sounds like it's used for JVM performance monitoring from the information I was able to dig up. I looked at the spec file for the Dogtag packages (pki-core), but I don't see that we execute java in %post. I also didn't see tomcat calling java in it's %post. I don't know what package is triggering the creation of hsperfdata_root.
As recommended on the freeipa-users list, I can confirm this issue, with some potential information about the reason why it may occur. Also, it it happening in F19. What I posted to the freeipa-users list: SELinux is preventing /usr/lib/jvm/java-1.7.0- openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/jre/bin/java from read access on the directory hsperfdata_root. For me, the problem was two-fold: 1. When creating a new VM, I typically issue 'systemctl mask tmp.mount' and reboot as a first rule, since I don't have the availability to have a huge chunk of the VM's allocated RAM used up for /tmp. 2. Beccause of 1., the /tmp directory persists across reboots, and after initial FreeIPA installation, the /tmp/hsperfdata_root diretctory and files have the system_u:object_r:rpm_script_tmp_t:s0 SELinux label, when they should have system_u:object_r:pki_tomcat_tmp_t:s0. I resolved this issue by stopping IPA, removing /tmp/hsperfdata_root, and rebooting the machine, where I was able to observe the directory and files created with the proper context. Without knowing the proper context beforehand, there was no way to issue a restorecon, since there is no default label for /tmp/hsperfdata_root.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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.
This problem was replicated in https://bugzilla.redhat.com/show_bug.cgi?id=1027285 Changes were made to fix 1027285. I do not see any of the AVC's from this bug anymore either. Closing this bug. Reopen it and update the product if this issue returns.