Description of problem: jetty fails to start as a service because it needs execmem access (jvm needs to execute the code produced by just-in-time compiler). The current policy has httpd_execmem disabled by default. The suggested solution was to set the boolean to 1 during the %post, but after evaluating, we've come to a conclusion that this is not acceptable for security reasons. The proper solution would be enabling execmem acces for java processes run in the httpd domain. This does not require enabling execmem for all processes, just for java processes (which always need execmem to run) Relevant part of the audit.log: type=SERVICE_START msg=audit(1396609719.063:486): pid=1 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(1396609719.079:487): avc: denied { execmem } for pid=1677 comm="java" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process type=SYSCALL msg=audit(1396609719.079:487): arch=c000003e syscall=9 success=no exit=-13 a0=7f6909000000 a1=270000 a2=7 a3=32 items=0 ppid=1672 pid=1677 auid=4294967295 uid=110 gid=110 euid=110 suid=110 fsuid=110 egid=110 sgid=110 fsgid=110 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.14.pre02.fc21.x86_64/bin/java" subj=system_u:system_r:httpd_t:s0 key=(null) type=SERVICE_STOP msg=audit(1396609719.082:488): pid=1 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=failed'
I don't understand you. For which security reason? We have the boolean for this case. If a user install jetty, httpd_execmem will turn on. >The proper solution would be enabling execmem acces for java processes run in >the httpd domain. This does not require enabling execmem for all processes, >just for java processes (which always need execmem to run) Not sure how you want us to do it? We would need to create a new domain for /usr/share/jetty/bin/jetty.sh and duplicate all rules which we have for httpd_t.
reasons: - if a user installs jetty, it would enable execmem access for all prcesses in httpd domain. I think it's not acceptable that installing a package would lower the security settings for unrelated packages and user processes. Jetty is a dependency for other packages, we need to avoid unexpected side-effects in scriptlets. - if we reset the boolean back in %postun, we can break other applications (or packages) that relied on this settings. If user installed something that needed execmem access and then uninstalled jetty, his application would break. If we don't reset it, the boolean will stay set even though it's not needed by anything. I'm not familiar with selinux policies. If it's not possible to make an exception from the rule just for Java processes then creating a new domain would probably be necessary.
(In reply to Michael Simacek from comment #2) > > I'm not familiar with selinux policies. If it's not possible to make an > exception from the rule just for Java processes It is not possible. But still this is why we have these booleans. Lot of pkgs/projects turn booleans on .. OpenShift for example. If you don't want to turn it on then you can add a note to README. httpd_execmem is "only" about httpd_t domain. If a user installs jetty which turns it on and then you turn it off, the alert tells you that you need to turn this boolean on.
Also we really try to avoid new policies which are not necessary.
My opinion on this, as a Jetty maintainer: Jetty cannot run al all without execmem -- that's simply how Java JIT works. This cannot be avoided or worked around. This applies to other servers too, like Tomcat or Wildfly. Enabling httpd_execmem boolean affects not only Java processes running in httpd domain, but also other daemons (like Apache httpd) which clearly don't need execmem. I believe that allowing execmem for the whole domain would lower system security and should be avoided if possible. IMO there should be a way to allow to allow Java-based servers to execute memory, while keeping others secure. If there is no other way then creating a separate domain may be worth looking into. That's a decision SELinux maintainers should make. In any case, I am against manipulating execmem boolean in Jetty scriplets, as this would negatively affect system security without user awareness. Documenting the need to manually tweak this boolean is a better option as it will let users a chance to considers security implications of doing so.
Well we could turn the boolean on in the install of the jetty package. Another option would be to put it in the unit file to turn it on if you enabled the jetty service. But it probably would be a bad idea to turn if off at service stop. Since the tools do not know if it was turned on before the service started.
(In reply to Daniel Walsh from comment #6) > Well we could turn the boolean on in the install of the jetty package. They don't want to do it.
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.
This is still a problem. I think jetty should have it's own policy, I don't really understand why it's running in httpd domain. Jetty is not httpd, it's not a httpd module, it doesn't use httpd and it's not used by httpd (only through mod_proxy). It's a servlet container. So is tomcat and it has it's own policy. Would it be possible to create one? It doesn't mean duplicating httpd rules, rather basing it on tomcat policy which should be more similar.
Lukas, could you look around?
Hi, After your last commit Michael, I think we could create new policy for this. I'll look at it.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
commit 1242c26164831629d8771b433ba4d551c398744f Author: Vit Mojzis <vmojzis> Date: Mon Aug 24 18:17:26 2015 +0200 Finish policy for jetty (previous version provided only interfaces - no entrypoint). #1084451 commit 88a1df366c768b11175fce869352e0edb89ef724 Author: Vit Mojzis <vmojzis> Date: Wed Aug 26 17:23:26 2015 +0200 Jetty policy fix - remove write access to /etc/ and /usr/share
selinux-policy-3.13.1-146.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14826
selinux-policy-3.13.1-146.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.