Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: jetty-8.1.0-4.fc17.noarch causes SELinux AVCs, won't start in enforcing mode
https://bugzilla.redhat.com/show_bug.cgi?id=797928
Summary: jetty-8.1.0-4.fc17.noarch causes SELinux AVCs, won't start in enforcing mode Product: Fedora Version: 17 Platform: x86_64 OS/Version: Linux Status: NEW Severity: unspecified Priority: unspecified Component: jetty AssignedTo: sochotni@redhat.com ReportedBy: selinux@gmail.com QAContact: extras-qa@fedoraproject.org CC: overholt@redhat.com, sochotni@redhat.com, java-sig-commits@lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: ---
Description of problem: jetty-8.1.0-4.fc17.noarch won't start in enforcing mode: it spews SELinux AVCs:
#============= initrc_t ============== allow initrc_t http_cache_port_t:tcp_socket name_bind; allow initrc_t hugetlbfs_t:file read; allow initrc_t self:process execmem;
Appears that /usr/share/jetty/bin/jetty.sh exec's Java while running under systemd's SELinux context ('initrc_t').
Shouldn't jetty/java transition to a different context (e.g., httpd_t, or a new 'jetty_t')? If so, probably need to add something so it can access /var/log/jetty.
Here are the actual AVCs from /var/log/audit/audit.log when I booted with 'enforcing=0':
type=SERVICE_START msg=audit(1330353641.267:29): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="jetty" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1330353642.590:31): avc: denied { read } for pid=747 comm="java" path=2F616E6F6E5F6875676570616765202864656C6574656429 dev="hugetlbfs" ino=17376 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:hugetlbfs_t:s0 tclass=file type=SYSCALL msg=audit(1330353642.590:31): arch=c000003e syscall=9 success=no exit=-12 a0=0 a1=200000 a2=3 a3=40022 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1330353643.581:33): avc: denied { execmem } for pid=747 comm="java" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=process type=SYSCALL msg=audit(1330353643.581:33): arch=c000003e syscall=9 success=yes exit=140008165998592 a0=7f5631000000 a1=270000 a2=7 a3=32 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1330353671.705:53): avc: denied { name_bind } for pid=747 comm="java" src=8080 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1330353671.705:53): arch=c000003e syscall=49 success=yes exit=0 a0=39 a1=7f563a0c74c0 a2=1c a3=7f563a0c7230 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=SOCKADDR msg=audit(1330353671.705:53): saddr=0A001F90000000000000000000000000000000000000000000000000
Version-Release number of selected component (if applicable): jetty-8.1.0-4.fc17.noarch selinux-policy-3.10.0-93.fc17.noarch
How reproducible: Every boot
Steps to Reproduce: 1. install jetty 2. boot 3.
Actual results:
Expected results:
Additional info:
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
--- Comment #1 from Stanislav Ochotnicky sochotni@redhat.com 2012-02-27 10:53:11 EST --- This is surprising to me, since I have tested this release on SELinux-enabled machine in enforcing mode and it run fine. Though that was right after installation without reboot being involved. However that should not play a role.
I have tried rebooting and the service still starts without a problem. Is there some post-install customization you have done before trying to start jetty?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
--- Comment #2 from Tom London selinux@gmail.com 2012-02-27 11:00:58 EST --- Nope, at least none that I'm aware of. I just updated to this and rebooted.
Here is 'ps' showing java running as initrc_t:
[root@tlondon modules]# ps agxZ | grep jetty system_u:system_r:initrc_t:s0 740 ? Sl 0:19 /usr/bin/java -Djetty.home=/usr/share/jetty -Djava.io.tmpdir=/tmp -jar /usr/share/jetty/start.jar --pre=etc/jetty-logging.xml staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 3558 pts/0 S+ 0:00 grep --color=auto jetty [root@tlondon modules]#
Here are java packages:
[root@tlondon modules]# rpm -qa *jdk* java-1.6.0-openjdk-1.6.0.0-65.1.11.fc17.x86_64 java-1.7.0-openjdk-devel-1.7.0.3-2.1.fc17.1.x86_64 java-1.6.0-openjdk-debuginfo-1.6.0.0-65.1.11.fc17.x86_64 java-1.6.0-openjdk-devel-1.6.0.0-65.1.11.fc17.x86_64 java-1.7.0-openjdk-1.7.0.3-2.1.fc17.1.x86_64 [root@tlondon modules]#
Here are selinux packages:
[root@tlondon modules]# rpm -qa selinux* selinux-policy-targeted-3.10.0-93.fc17.noarch selinux-policy-3.10.0-93.fc17.noarch [root@tlondon modules]#
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
Stanislav Ochotnicky sochotni@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #3 from Stanislav Ochotnicky sochotni@redhat.com 2012-02-27 11:46:06 EST --- Perhaps it is to do with 6.x to 8.x upgrade rather than more recent systemd transition. Will have a closer look
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
--- Comment #4 from Daniel Walsh dwalsh@redhat.com 2012-02-27 11:49:54 EST --- Stanisav, the reason it is working for you versus Tom, is Tom runs his machine with a much more locked down environment. Tom's system has unconfined.pp disabled meaning, he does not have any unconfined domains running on his box. jetty is running as initrc_t which is an unconfined domain, and thus works on your box. We have changed the labeling on the lates policy to run jetty under the same label as httpd.
The only problem I am aware of now is that jetty needs to have the httpd_execmem boolean turned on to work and you are writing to your log files rather then appending to them. SELinux will prevent this.
We might want to turn on the httpd_execmem boolean in your post install or turn it on and off when you start and stop the service.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
--- Comment #5 from Fedora End Of Life endoflife@fedoraproject.org --- This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'.
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 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 17'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.
https://bugzilla.redhat.com/show_bug.cgi?id=797928
Fedora End Of Life endoflife@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |WONTFIX Last Closed| |2013-08-01 14:07:15
https://bugzilla.redhat.com/show_bug.cgi?id=797928
--- Comment #6 from Fedora End Of Life endoflife@fedoraproject.org --- Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.
Thank you for reporting this bug and we are sorry it could not be fixed.
java-sig-commits@lists.stg.fedoraproject.org