Description of problem: rule=12 dec=deny_audit perm=open auid=-1 pid=16015 exe=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.312.b07-2.el8_5.x86_64/jre/bin/java : path=/var/lib/pki/pki-tomcat/work/Catalina/localhost/ROOT/org/apache/jsp/index_jsp.java ftype=text/x-java trust=0 Version-Release number of selected component (if applicable): 100% How reproducible: ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57 Steps to Reproduce: 1. start fapolicyd with the default policy 2. install IPA using ipa-server-install Actual results: certificate server install failes Expected results: IPA is installed Additional info: worked with ipa-server-4.9.2-4.module+el8.4.0+11156+94d209c1
The CA installation fails how? Please provide the server installation log plus the spawn and debug logs found in /var/log/pki (and below) Re-assigning to pki-core component as this is CA-related.
Please, investigate.
The issue is we have an untrusted java file being accessed by an interpreter. The fapolicyd rule is that scripts need to be trusted. How did the java file get installed to /var/lib/pki/pki-tomcat/work/Catalina/localhost/ROOT/org/apache/jsp/ ? Was it by rpm? Did someone just open an archive?
The work directory contains temporary working directories for the deployed web applications. What happened is that your ROOT webapp tried to compile the index.jsp, and failed for some reason. The java file was being created in that temp directory as a result of that real time JSP compilation, so whatever manages /var/lib/pki/pki-tomcat/webapps/ROOT/index.jsp is the culprit :) After some quick Googling to learn more about fapolicyd, I found https://access.redhat.com/solutions/5567781 which seems to be a solution? Maybe we need to add some additional rules to the default policy to cover this case?
That's what I'm trying to figure out. Do we need to change rules or is something not registering trust correctly. Since it's a temporary copy, trust is not the right solution. I'd change the suggested rules from that kb to include trust=1 on the subject side. But the suggested rule otherwise should solve the problem. I suppose this should get added to the rules that we ship. Reassigning to fapolicyd. Thanks for the discussion.
(In reply to Steve Grubb from comment #10) > That's what I'm trying to figure out. Do we need to change rules or is > something not registering trust correctly. Since it's a temporary copy, > trust is not the right solution. I'd change the suggested rules from that kb > to include trust=1 on the subject side. But the suggested rule otherwise > should solve the problem. I suppose this should get added to the rules that > we ship. Reassigning to fapolicyd. Thanks for the discussion. I agree that trusting a temporary copy probably isn't a great idea, so maybe the PKI folks want to precompile the JSP beforehand (rather than compiling at runtime) and package that compiled class in the webapp? You still need to add a rule to the policy to trust it, but it would be permanent and in a better controlled location. See more info about precompilation of JSPs within a webapp at https://tomcat.apache.org/tomcat-9.0-doc/jasper-howto.html#Web_Application_Compilation :D
If this were fixed by precompiling the application, then it would be packaged and rpm would have a SHA256 hash for it making it automatically trusted. That would be a better solution than adding rules.