Contrary to the usual practice, setting SELinux to
permissive mode and recording all AVC denials in order to develop a policy module can result in a wrong set of permissions being included in such policy.
An example of this could be the following: suppose that this proprietary software normal operation requires a domain transition, in permissive mode, the transition does not happen and it looks like the source domain requires all the permissions recorded as AVC denials (Sven Vermeulen's SELinux Cookbook contains several references to this potential problem).
A better approach to create a policy module for a proprietary software would be to maintain SELinux in enforcing mode in the first place, to ensure the least privilege possible is being granted.
Next would be to research the software, both online (does it have documentation?) and offline (
ipcs, ...) to determine in detail its architectural design, namely, but not limited to:
files, which should also be divided in subgroups (configuration, transactions, logs, ...)
processes, services (does the software have a systemd/upstart/init script?)
network connectivity (inbound and outbound traffic, ports, ...)
With all that information at hand, you would be able to start developing a policy for that software.
You will need to:
create a filecontexts file defining the security context of all the files involved
create an interfaces file defining your domain in terms of all the interactions between files, processes, ports, users, domain transitions, ...
create a type enforcement file describing which users are granted access to the domain above and the actual rules
Compile it and load it, check the AVC denials, debug and enhance your policy. Rinse and repeat.
From the book referred above, one last quote:
Some policy developers like to run application permissive mode (either by running the entire system in permissive mode or by marking this particular domain as a permissive domain), registering all accesses performed (through the AVC denials) and enhancing the policy based on that information. Although this might give a faster working policy, these developers will also risk that they add too many privileges to a policy, something that is very difficult to challenge and change later.
Instead, we let SELinux prevent accesses and look at how the application reacts. Based on the error logging of the application or the behavior of the application and the AVC denial(s) seen through the logs, we can have a good picture of what privileges are really needed.