Bug 2074215

Summary:	ipa executes an arbitrary untrusted code which is being blocked by fapolicyd
Product:	Red Hat Enterprise Linux 8	Reporter:	Dalibor Pospíšil <dapospis>
Component:	pki-core	Assignee:	RHCS Maintainers <rhcs-maint>
Status:	NEW ---	QA Contact:	idm-cs-qe-bugs
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	8.5	CC:	ckelley, csutherl, fdelehay, mfargett, rcritten, rhcs-maint, rsroka, sgrubb, tscherf
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	tscherf: needinfo? (pcech)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2074220 (view as bug list)		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dalibor Pospíšil 2022-04-11 19:16:51 UTC

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

Comment 1 Rob Crittenden 2022-04-11 19:30:49 UTC

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.

Comment 3 Petr Čech 2022-04-19 15:23:09 UTC

Please, investigate.

Comment 6 Steve Grubb 2022-05-24 18:58:50 UTC

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?

Comment 9 Coty Sutherland 2022-05-31 18:48:14 UTC

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?

Comment 10 Steve Grubb 2022-05-31 21:08:05 UTC

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.

Comment 13 Coty Sutherland 2022-06-01 14:45:28 UTC

(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

Comment 14 Steve Grubb 2022-06-01 17:04:42 UTC

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.