Thank you for reporting the issue, could you please provide us with versions of the following packages in your system?

$ rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*" "libsepol*" "libsemanage*"

Also please try to update libsepol and policycoreutils-python packages and see if the problem persists.

# yum update "libsepol*" "policycoreutils*"

(In reply to Vit  Mojzis from comment #2)
> Thank you for reporting the issue, could you please provide us with versions
> of the following packages in your system?
> 
> $ rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*"
> "libsepol*" "libsemanage*"
> 
> Also please try to update libsepol and policycoreutils-python packages and
> see if the problem persists.
> 
> # yum update "libsepol*" "policycoreutils*"

rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*" "libsepol*" "libsemanage*"
libselinux-devel-2.5-12.el7.x86_64
libselinux-python-2.5-12.el7.x86_64
libsemanage-python-2.5-5.1.el7_3.x86_64
setools-libs-3.3.8-1.1.el7.x86_64
libsepol-2.5-8.1.el7.x86_64
libsemanage-2.5-5.1.el7_3.x86_64
selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
policycoreutils-2.5-11.el7_3.x86_64
selinux-policy-3.13.1-102.el7_3.4.noarch
libselinux-2.5-12.el7.x86_64
libsepol-devel-2.5-8.1.el7.x86_64
policycoreutils-python-2.5-11.el7_3.x86_64
libselinux-utils-2.5-12.el7.x86_64

Can you tell from the above versions itself about any problems? I don't want to disturb the test environment for now. Also, if I put the system in permissive mode, then above issue is not seen.

JFYI .. This is my chat on the selinux channel about this issue..

* Now talking on #selinux
* Topic for #selinux is: English channel about NSA Security Enhanced Linux. (Denna kanal engelsk, #linux.se e svensk.) Please be patient, we're not always here, but we do like to chat so hang around. FAQ: https://selinuxproject.org/page/FAQ | http://reddit.com/r/selinux
* Topic for #selinux set by pebenito!~pebenito@unaffiliated/pebenito (Wed Mar 14 05:59:56 2018)
<aarora06> Hi! I faced an issue on selinux on RHEL 7.3 x86_64 system. Please check this defect: https://bugzilla.redhat.com/show_bug.cgi?id=1592775.
<grift> you can either use audit or add aan auditallow rule
<aarora06> I researched a little about it and a similar defect was faced with policy.20 file some time ago. Basically, I can see policy.30 and policy.31 files under /etc/selinux/targeted/policy directory which is causing the issue. And this is very rarely reproducible.
<grift> aarora06; what answer are you looking for?
<grift> remove the policy.30 file then see if you can reproduce
<aarora06> grift: Do you know what can cause such an issue where 2 policy files are created on a system
<grift> yes upgrades
<aarora06> rpm -qf policy.31 --> /etc/selinux/targeted/policy/policy.31 is not owned by any package and rpm -qf policy.30 --> selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
<aarora06> So, policy.31 file is the extra one created
<grift> yes so i suppose userspace and kernel were upgraded but the policy package doesnt reflect it
<grift> aarora06: its ugly upgrade but i suppose you shouldnt be able to reproduce it when you remove policy.30
<grift> and i suppose selinux-policy packages need to be updated to reflect the policyversion update
<aarora06> ok .. so this can be due to an issue with the repo that is setup which contains related rpms right?
<grift> aarora06: yes i suppose it can
<grift> maybe the policy package wasnt upgrade in the same transaction as the userspace package and or kernel pacakge
<grift> aarora06: selinux is 3 componeents, the kernel, the policy and the utils and libs
<aarora06> hmm .. so what is meant by userspace package and kernel package? Are these some specifically named package needed by selinux-policy-targeted? I am not sure I understand that part..
<grift> so all need to be updated if theres a major version change to selinux
<grift> user space packages are like libselinux libsepol but also policycoreutils* libsemanage semanage etc
<grift> policy is selinux-policy*
<aarora06> ok..
<grift> so when theres a policy version bump (that signal that the kernel learned new selinux trichs( everything needs to be made aware (recompiled)
<aarora06> so this would be an issue with dependencies right? All rpms should have had proper requires part to handle this right?
<grift> and in your case it seems that your policy package was still unaware of it
<grift> i suppose yes
<aarora06> ok..
<grift> but if you remove the policy.30 then it should be ok
<grift> atleast semi-ok
<grift> and run semodule -B
<grift> it will recompile the policy.31
<aarora06> I think in this policy.31 file should be removed because it is not owned by any package in my case..
<aarora06> rpm -qf policy.31 --> /etc/selinux/targeted/policy/policy.31 is not owned by any package and rpm -qf policy.30 --> selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
<grift> naw you wont be able to stop it from compiling the 31 anyway
<grift> everything uses 31 now except that selinux-policy package
<grift> so as soon as you do anything selinux is will compile 31
<grift> try it out
<aarora06> ok..
<grift> mv the policy.* files
<grift> then run semodule -B
<grift> and look in the dir
<grift> youll see that theres a policy.31
<grift> thats because the userspace will try to build the latest polvers
<aarora06> I will try that Thanks!
<grift> its just like you said, they should probably have some requires to make it consistent
<grift> but its easitly resolved just rm policy.30 && semodule -B
<grift> and then wait for an updates selinux-policy
<grift> updated
<aarora06> yes .. policy.31 got created
<grift> so its just that the selinux-policy package wasnt compiled against the new user space or that theres a bug in the spec file
<grift> probably the former
<aarora06> when would the former happen?
<grift> well when the kernel and selinux userspace are upgraded to a version that has new selinux features
<grift> but not the policy package
<grift> afaik its exactly as you said
<aarora06> yes .. but then this would again be an issue with spec file right? The spec file Requires should be responsible to make it consistent..
<grift> there probably should have been a require in the selinux user space to say, hey this update needs an updates selinux-policy
<aarora06> yes
<grift> yes thats how i see it
<aarora06> ok.. I will post this chat on that bug so that the redhat team looks into it this way
<grift> o theyll know
<aarora06> ok
<aarora06> thanks!
<grift> its a bit late now though and this wont happen again in the foreseeable future
<grift> arguable the bug is in semaange and whatever libs it uses
<grift> it should probably be smart enough to just pick the previous polvers
<grift> but even then ...
<grift> actually you can probably tell semanage to use 30
<grift> in /etc/selinux/targeted/semanage.conf
<grift> so that would have been another option
<grift> to just tell selinux, keep using version 30 regardless
<aarora06> ok.. how is that done
<grift> https://manpages.debian.org/testing/libsemanage-common/semanage.conf.5.en.html
<aarora06> Also is it "safe"/recommended to use..
<grift> policy-version When generating the policy, by default semanage will set the policy version to POLICYDB_VERSION_MAX, as defined in <sepol/policydb/policydb.h>. Change this setting if a different version needs to be set for the policy.
<grift> so i suppose echo "policy-version = 30" >> /etc/selinux/targeted/semanage.conf && semodule -B && ls -lh /etc/selinux/targeted/policy/
<grift> not recommended in general
<aarora06> Ok .. got that..
<grift> because if the policy would leverage a feature of polvers 31 then the compiler might tell you it doesnt know that feature i gather
<grift> gather
<aarora06> ok..
<aarora06> One more question: When using this command for regenerating the policy file - "semodule -B" -> Will this affect existing policies that user might have set for enforcing mode?
<aarora06> I guess it should..
<grift> no
<grift> its just recompiles the modules that are installed
<grift> ie it recompiles the policy.X file
<aarora06> ok .. so it is a harmless operation for a user using selinux?
<grift> so if you installed a .pp then that will be included as expected
<grift> yes
<aarora06> ok
<grift> its just like a "refresh"
<aarora06> Also, rpm -qf policy.31 -> file /etc/selinux/targeted/policy/policy.31 is not owned by any package -> Is this expected ? (This is after refresh..)
<grift> yes expected since its not owned by any package
<grift> policy.30 is
<aarora06> hmm.. 
<grift> so eventaully that will solve itself
<aarora06> why is there that difference..
<grift> once you update selinux-policy to a version that supports new user space
<grift> because selinux-policy you have installed , installed the old policy.30 file
<grift> but userspace wss upgraded and that compiles 31
<grift> so until you update to an selinux-policy that installs policy.31 youll get that
<grift> buts its just cosmetic
<grift> its an historicall thing
<grift> you see building that policy.X file takes some time
<grift> so to save time the selinux-policy package tries to copy a precompiled policy.X file
<grift> but that file only gets installed on new installation probably
<grift> so actually i really think its just a selinux-policy.spec bug
<grift> anyhow its no big deal
<aarora06> ok.. so to save time the selinux-policy package tries to copy a precompiled policy.X file --> and that is why it shows as being owned by selinux-policy-targeted..?
<grift> yes
<grift> if the package installs the file then it shows up in the rpm -qf
<grift> and in this case the policy.31 isnt installed by the package
<grift> its compiled with semodule -B, since you selinux-policy package still uses version 30 seemingly
<grift> but they will figure it out
<grift> just know that if you rm policy.30 and semodule -B, you should be fine
<aarora06> ok..
<grift> you dont even need to rm policy.30
<grift> just a semodule -B should do it
<aarora06> ok..

So, by refreshing the policy files by using this command : "semodule -B" and also updating the 2 packages mentioned in comment 2 : "libsepol*" "policycoreutils*" - the issue was resolved. 

To resolve this issue, Requires section should be appropriate for selinux packages in their spec files (such that only one policy file is generated).

Hi .. Is there a plan to fix this? Also, will that be in the next version or is the version with the fix is already out?

Is this defect resolve and out?

We are sorry, but the issue was not addressed yet. We improved the dependency chain in the latest versions of userspace and policy packages, but as of now we do not know what caused the partial update (updated userspace with old policy) in your system. Therefore we cannot be sure that the issue was resolved.
We will try to improve policy version handling in RHEL 7.7.

If you are not satisfied with this time frame, please escalate the issue via customer portal.

Thanks Mojzis. When is release date of RHEL 7.7. ?

That is not publicly available information.
Please see general guidelines regarding releases [1] or contact customer support for more information.

[1] https://access.redhat.com/support/policy/updates/errata/

This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.