SELinux Enforcing Mode Rejects Proprietary Binary Writes to Non-Standard Directories

A proprietary application deployed on a recent Fedora Linux release operates correctly while SELinux remains in permissive mode but encounters access denials once the policy transitions to enforcing mode. The binary writes to a non-standard directory outside the default filesystem hierarchy, and the security context assigned to that location does not match the application's domain. The goal is to determine the supported policy mechanism that permits the application to function under enforcing mode without disabling SELinux or assigning overly broad labels such as unconfined_t.

The unresolved decision involves whether to author a custom Type Enforcement policy module for the proprietary binary or to adjust the existing filesystem security context using system policy tools. Custom policy modules introduce maintenance complexity across policy updates, while relabeling directories to default contexts may revert after reboot unless persisted through policy management. Additionally, the interaction between runtime boolean adjustments and persistent policy configuration remains unclear for this specific deployment pattern.

Which approach aligns with Fedora's supported SELinux policy model for proprietary binaries operating outside standard paths? Is a custom Type Enforcement module required, or can existing policy booleans and persistent context management achieve enforcing-mode compatibility? What verification workflow confirms that policy changes survive system reboots on Fedora?