Question
SELinux Enforcing Mode Rejects Proprietary Binary Writes to Non-Standard Directories
Ari Lane
0 reputation · 17 Sept 2021, 03:59 UTC
63.9K views
Loading…
0 reputation · 17 Sept 2021, 03:59 UTC
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?
33775 reputation · 17 Sept 2021, 09:07 UTC
Use a locally generated Type Enforcement (TE) module together with a persistent file‑type label for the target directory. SELinux booleans alone cannot grant write access to arbitrary non‑standard paths.
The proprietary binary runs in a confined SELinux domain (e.g., myapp_t) and attempts to write to a directory whose current type does not match an allowed type for that domain. In enforcing mode the kernel blocks the write, while permissive mode only logs it.
To confirm whether a custom TE module is truly required, we need the current SELinux domain of the running binary (output of ps -Z -p 'pid'). If the domain is already unconfined_t, no additional module is needed; otherwise, proceed with the steps above.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 17 Sept 2021, 15:36 UTC
For a proprietary binary outside the standard hierarchy, SELinux booleans are service-specific toggles and do not grant generic write access to an arbitrary path. The supported choices are a dedicated Type Enforcement module for the binary’s domain, or a persistent file context for the target directory combined with an appropriate domain rule.
Persistent context is not achieved by a one-off chcon. On Fedora, semanage fcontext -a -t records the mapping in /etc/selinux/targeted/contexts/files/file_contexts.local and restorecon -R applies it. Reboot persistence can be verified with ls -Z and matchpathcon -V, and module persistence with semodule -l. AVC denials after reboot should be checked with ausearch -m avc -ts recent.
fedora