Log/Audit everything allowed by SELinux

Question

I'm profiling some proprietary software to construct a set of permission requirements and SELinux policies to allow it to install and run on Oracle Linux (or any RHEL derivative).

I'm running SELinux in permissive mode, I have run semodule -DB to disable "dontaudit" and I am viewing /var/log/audit/audit.log to see the results.

However I would like to also see EVERYTHING that was allowed (not just denials or auditallow), which seem to be the majority judging by this:

[root@aw-selinuxtest ~]# seinfo --stats

Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)

   Classes:            81    Permissions:       237
   Sensitivities:       1    Categories:       1024
   Types:            3852    Attributes:        291
   Users:               9    Roles:              12
   Booleans:          228    Cond. Expr.:       268
   Allow:          311381    Neverallow:          0
   Auditallow:        133    Dontaudit:           0
   Type_trans:      38576    Type_change:        38
   Type_member:        48    Role allow:         19
   Role_trans:        368    Range_trans:      5601
   Constraints:        90    Validatetrans:       0
   Initial SIDs:       27    Fs_use:             24
   Genfscon:           84    Portcon:           471
   Netifcon:            0    Nodecon:             0
   Permissives:        91    Polcap:              2

Does anyone know how to do this? I'm struggling to find an answer so far.

Answer 1

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 (ss, strace, 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, ...)

• users, groups

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.