Bug 2038914

Summary:	Java Application Pod failing due to selinux policy
Product:	Red Hat Enterprise Linux 8	Reporter:	RAUNAK BORKAR <rborkar>
Component:	container-selinux	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED NOTABUG	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.5	CC:	jnovy, lvrabec, mmalik, ssekidde, tsweeney, zpytela
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-07 18:40:31 UTC	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 RAUNAK BORKAR 2022-01-10 14:35:35 UTC

Description of problem:
Customer is facing issue with their java application failing with error:
/bin/sh: error while loading shared libraries: /lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied

This issue is faced on one of the node from the cluster. The java application is failing on a particular node while it's running fine on other nodes.

We saw some selinux denies in the sos report.
By Default the selinux policy is set to enforcing, so we asked customer to change the policy to permissive, after the change, pod is running fine on the node.

But it should work with enforcing mode like all other nodes in the cluster.
So raising the bug

Version-Release number of selected component (if applicable):
[redhat-release] Red Hat Enterprise Linux CoreOS release 4.8
[os-release] Red Hat Enterprise Linux 8.5 (Ootpa) 8.5 (Ootpa)


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
Java Application Pod failing in enforcing mode

Expected results:
Java Application Pod should work in enforcing mode


Additional info:

Comment 2 Zdenek Pytela 2022-01-10 14:40:43 UTC

Please share reproducing steps and audit records with full auditing enabled.


1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 9 Zdenek Pytela 2022-01-14 11:03:33 UTC

Switching the component for further investigation.

Comment 10 Daniel Walsh 2022-02-07 18:40:31 UTC

This is two containers attempting to share the same content.


applicationset running as 
scontext=system_u:system_r:container_t:s0:c39,c52 

Trying to read

/usr/local/bin/applicationset-controller
tcontext=system_u:object_r:container_file_t:s0:c443,c612 tclass=file permissive=0

This file if it is on disk should be labeled as bin_t. And then it would be allowed.

This is not a container-selinux problem.