Hi Team,

Creating this issue on behalf of an IBM team who is concerned on the mentioned scenario:

Background: Persistent permission issues within our containerized environment have been identified, particularly related to SELinux denials affecting essential operations such as file access (read, write, append) and process transitions.

Objective: The primary goal is to configure SELinux policies/mode in a way that allows necessary operations within containers while adhering to security best practices, without the need for custom policy creation at runtime.

Current Situation:
SELinux Configuration: SELinux has been temporarily set to permissive mode (setenforce 0) to mitigate permission denials during troubleshooting.

Audit Logs Analysis: Audit logs (ausearch) have consistently shown denials impacting operations such as file access (read, write, append) and process transitions (entrypoint, transition), affecting containerized applications.

Example Denials:
css
Copy code
avc: denied { entrypoint }
avc: denied { transition }
avc: denied { read }
avc: denied { append open }
avc: denied { create }
avc: denied { add_name }
avc: denied { write }
avc: denied { open }
avc: denied { dyntransition }
avc: denied { search }

Challenges with Custom Policies: Due to the stringent security measures implemented, including a locked-down image environment with restricted SSH access and the application of confidential computing principles, creating and deploying custom SELinux policies dynamically in staging or production environments poses significant challenges. Custom policies would require periodic updates to align with specific customer application workloads and their varying filesystem access requirements. However, due to the restricted nature of the environment, relying on custom policies is not feasible for this approach.

 
So, we want to know whether Permissive mode is allowed in locked down instances as we have issues with enforcing mode.