Is it possible to include a fully-working SELinux policy with B2B software?
Preamble
I'm an engineer at a small company that sells B2B software for various OSes, including RHEL. The software usually runs natively (as a statically compiled binary) and uses/accesses system resources like raw sockets, the /proc filesystem, iptables, etc. The exact resources depend on how the software is configured during installation, as well as dynamic events encountered during runtime.
A customer has asked us to "provide SELinux support" for the software. Using Red Hat's documentation and The SELinux Notebook, we were able to create a custom policy for the application. We generated the policy in a local development environment by:
- Switching SELinux to "permissive" mode,
- Running our software for an extended period while exercising as many code paths as possible,
- Creating a policy module from the reported violations using
ausearchandaudit2allow - Verifying that the application ran as expected when running in "enforcing" mode.
When the customer went to install the policy in their own environment, however, the application still triggered a number of violations that weren't raised in our environment, even though the same resources were being accessed as the ones we tested for.
Questions
- Is there a better way to generate a policy than by just running the software for a week and manually catching violations?
- Is there a way to anticipate violations in a customer environment without having access to said environment?
- Is there a way to provide a policy that "just works" in their environment, without them running as "unconfined" and without them having to go through the same "run it for a few days in permissive and use
ausearch/audit2allow" cycle?
After some investigation, we came to the general conclusion that the above issue we experienced is actually SELinux "working as intended," but the tools in the ecosystem are quite complex, and I'm eager to hear your feedback or responses to the above questions. Thanks!
