Bug 797928 - jetty-8.1.0-4.fc17.noarch causes SELinux AVCs, won't start in enforcing mode
Summary: jetty-8.1.0-4.fc17.noarch causes SELinux AVCs, won't start in enforcing mode
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: jetty
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Stanislav Ochotnicky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-27 14:52 UTC by Tom London
Modified: 2013-08-01 18:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-01 18:07:15 UTC
Type: ---


Attachments (Terms of Use)

Description Tom London 2012-02-27 14:52:39 UTC
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:

Comment 1 Stanislav Ochotnicky 2012-02-27 15:53:11 UTC
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?

Comment 2 Tom London 2012-02-27 16:00:58 UTC
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]#

Comment 3 Stanislav Ochotnicky 2012-02-27 16:46:06 UTC
Perhaps it is to do with 6.x to 8.x upgrade rather than more recent systemd transition. Will have a closer look

Comment 4 Daniel Walsh 2012-02-27 16:49:54 UTC
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.

Comment 5 Fedora End Of Life 2013-07-04 06:31:57 UTC
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.

Comment 6 Fedora End Of Life 2013-08-01 18:07:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.