Hi Frank,
Did you booted with SELinux disabled and then turned SELinux in enforcing mode again? 

Could you please run following command:
# restorecon -R / 

Then try to repeat the scenario? 

Thanks.

Selinux was never disabled on this system.
before restorecon -R / :
ll -Z /var/ 
drwxr-xr-x. root      root          system_u:object_r:kdump_crash_t:s0 crash
after:
drwxr-xr-x. root      root          system_u:object_r:kdump_crash_t:s0 crash
trigger an kernel panic:
abrt-harvest-vmcore[2438]: VMCore dir '/var/crash/127.0.0.1-2017-01-12-09:03:13' not accessible.

But what I can see is:
ll -Z /var/crash/
drwxr-xr-x. root root system_u:object_r:kdump_crash_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 127.0.0.1-2017-01-12-09:03:13

that the crash directory itself has an different context.  


restorecon -R /var/crash/
systemctl restart abrt-vmcore
systemctl reboot
Now the crash are recognized:
systemd[1]: Starting Harvest vmcores for ABRT...
systemd[1]: Started Harvest vmcores for ABRT.
abrt-dump-oops[2410]: Found oopses: 1
abrt-dump-oops[2410]: Updating problem directory

Hi Martin, could you help us to reproduce the issue? We need to know the SELinux labels of directories inside /var/crash directory.

# setenforce 0
# ls -Z /var/crash

It seems that /var/crash/127.0.0.1-2017-01-12-09:03:13 was created with an invalid SELinux label.

We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.

We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.

The same will happens on RHEL 8.3. :(

Frank,

Could you provide more details on your setup? Namely about /var/crash: is it a separate filesystem? Are there some special conditions to trigger the denial in addition to the bz description?

mount
ls -laZ /var/crash
ausearch -i -m avc,user_avc -ts boot
restorecon -Rvn /var/crash
(will not change any label)

I have tried both scenarios, /var/crash on the / and on an separate file system. But the result is the same.
But after some testing it looks like the bad guy it the kernel dumper itself, because when I create an test directory via mkdir /var/crash/foo, then /var/crash/foo will have the right context.
Only the when the subdirectory directory is created by an kernel crash, then it will have the wrong context. For testing I trigger kernel crash via:
echo 1 > /proc/sys/kernel/sysrq 
echo c > /proc/sysrq-trigger

This issue was not selected to be included in Red Hat Enterprise Linux 8 because it is seen either as low or moderate impact to a small number of use cases.

That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.