This happens regularly in Fedora 25 and breaks core dumping on the system. This is a regression.
It prevents us from making progress debugging other issues in components like storaged.
For example here's a segfault that we didn't get a core dump for, and are unable to make progress solving:
https://fedorapeople.org/groups/cockpit/logs/pull-4565-d063ad01-verify-fedora-25/TestStorage-testLvm-10.111.120.109-FAIL.log
The reproducer for this above is simple and consistent. In addition here's another trivial consistent reproducer:
# systemctl start crond
# killall -SEGV crond
# ls /var/lib/systemd/coredump/
# setenforce 0
# systemctl start crond
# killall -SEGV crond
# ls /var/lib/systemd/coredump/
core.crond.0.f0be89cae1e34090ab645453bdd4f1c4.1348.1478864770000000000000.lz4
After "setenforce 0" it works. There are no denied messages in the journal:
# journalctl -b | grep denied
<no output>
The above system is a clean install of Fedora 25. Built on October 22nd. It was built with the following packages (ie: no ABRT):
%packages
@core
%end
In addition if you wish to have an actual image you can get it here:
https://fedorapeople.org/groups/cockpit/images/fedora-25-c6ac0dbaf59ea4ecc5b07aaa0bcd7f307a0c1e31.qcow2.xz
Once again:
# rpm -qa | grep selinux
rpm -qa | grep selinux
selinux-policy-targeted-3.13.1-220.fc25.noarch
selinux-policy-3.13.1-220.fc25.noarch
libselinux-python3-2.5-12.fc25.x86_64
rpm-plugin-selinux-4.13.0-0.rc1.46.fc25.x86_64
container-selinux-1.12.2-3.git15c82b8.fc25.x86_64
libselinux-2.5-12.fc25.x86_64
libselinux-utils-2.5-12.fc25.x86_64
# rpm -qa | grep systemd
systemd-231-10.fc25.x86_64
systemd-udev-231-10.fc25.x86_64
systemd-libs-231-10.fc25.x86_64
systemd-container-231-10.fc25.x86_64
systemd-pam-231-10.fc25.x86_64
python3-systemd-232-1.fc25.x86_64
python-systemd-doc-232-1.fc25.x86_64
rpm-plugin-systemd-inhibit-4.13.0-0.rc1.46.fc25.x86_64
oci-systemd-hook-0.1.4-4.git15c2f48.fc25.x86_64

Proposed as a Blocker for 25-final by Fedora user sgallagh using the blocker tracking app because:
"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." (Final criterion)
It might be arguable, but I'd claim that ABRT wouldn't be withstanding the basic functionality test if SELinux is preventing coredumps from being generated and therefore displayed in ABRT.

I don't think it is. We've reported dozens of F25 crashes via abrt just fine. I just tested - with the same selinux-policy you have, 220.fc25, though in fact what's going into Final is -224 - and if I pkill gedit I get an abrt crash report, including coredump, just fine.
On that basis, -1 blocker, I don't see any criterion violation here.

(In reply to Lukas Vrabec from comment #7)
> Here is the workaround:
>
> # cat crond_rhlimith.cil
> (allow init_t crond_t (process (rlimitinh)))
That does fix it for a segfault in the crond process. What's an equivalent line that works for any other process? I'd like to put this workaround into our integration tests.

Isn't this a duplicate of bug #1341829? It has been broken since F24. If Lukas is going to fix it, that saves us all some effort as it's derailing my coredumpctl by default effort and we were planning to escalate this issue to FESCo. :)
(In reply to Fedora Blocker Bugs Application from comment #4)
> It might be arguable, but I'd claim that ABRT wouldn't be withstanding the
> basic functionality test if SELinux is preventing coredumps from being
> generated and therefore displayed in ABRT.
Do you have the abrt-ccpp plugin disabled on Server? If not, ABRT should still work fine. This bug is causing no issues with ABRT on Workstation. It would definitely break ABRT in combination with our desired switch to enable coredumpctl by default in F26, but we're not there yet.

(In reply to Lukas Vrabec from comment #11)
> (In reply to Stef Walter from comment #8)
> > (In reply to Lukas Vrabec from comment #7)
> > > Here is the workaround:
> > >
> > > # cat crond_rhlimith.cil
> > > (allow init_t crond_t (process (rlimitinh)))
> >
> > That does fix it for a segfault in the crond process. What's an equivalent
> > line that works for any other process? I'd like to put this workaround into
> > our integration tests.
>
> Stef,
> Just change allow rule:
> (allow domain domain (process (rlimitinh)))
Lukas, we need the SELinux policy to be updated to work generally, because right now it prevents coredumpctl from working on Fedora, which is a very important for debugging and improving Fedora quality.

(In reply to Lukas Vrabec from comment #13)
> Stephen,
> Do we need to allow this for every domain on the system?
I think so, yes. Since any process on the system could crash and need to be captured.
> Probably we should create a boolean for this.
Doesn't make sense to me. By the time you realize you need to set the boolean, you would have already missed the crash you wanted to capture.

(In reply to Stephen Gallagher from comment #14)
> (In reply to Lukas Vrabec from comment #13)
> > Stephen,
> > Do we need to allow this for every domain on the system?
>
> I think so, yes. Since any process on the system could crash and need to be
> captured.
>
> > Probably we should create a boolean for this.
>
> Doesn't make sense to me. By the time you realize you need to set the
> boolean, you would have already missed the crash you wanted to capture.
I agree. The goal should be that systemd and systemd-coredump just works. Why do we need to set a boolean to unbreak this feature of systemd?

Lukas, please do what you need to do to make the feature work as designed without any modifications to SELinux policy. If the problem is really just that SELinux is preventing systemd from raising the rlimit, then I'd say we don't need to allow every process on the system to do that..
Also: is this bug a duplicate of bug #1341829?

(In reply to Michael Catanzaro from comment #9)
> (In reply to Fedora Blocker Bugs Application from comment #4)
> > It might be arguable, but I'd claim that ABRT wouldn't be withstanding the
> > basic functionality test if SELinux is preventing coredumps from being
> > generated and therefore displayed in ABRT.
>
> Do you have the abrt-ccpp plugin disabled on Server? If not, ABRT should
> still work fine. This bug is causing no issues with ABRT on Workstation. It
> would definitely break ABRT in combination with our desired switch to enable
> coredumpctl by default in F26, but we're not there yet.
I've seen references in a few reports to the fact that systemd-coredump isn't supposed to be enabled on F25 Workstation, but it is on my system despite never taking any action to do so. Even though abrt-ccpp.service is enabled, systemd-coredump appears to set its core pattern into the kernel after ABRT does, thus overriding it, so it ends up trying (and failing) to handle the coredump instead. If I restart abrt-ccpp.service after bootup, ABRT starts working.
I don't know how systemd-coredump is supposed to be disabled, since all of the settings in systemd config files seem to be at default (rpm -V systemd shows no output). Sure looks like it's enabled by default in F25 to me, unless the installer has some magic to modify the settings (this system was upgraded several times from previous Fedora versions).

(In reply to Robert Hancock from comment #17)
> I've seen references in a few reports to the fact that systemd-coredump
> isn't supposed to be enabled on F25 Workstation, but it is on my system
> despite never taking any action to do so. Even though abrt-ccpp.service is
> enabled, systemd-coredump appears to set its core pattern into the kernel
> after ABRT does, thus overriding it, so it ends up trying (and failing) to
> handle the coredump instead. If I restart abrt-ccpp.service after bootup,
> ABRT starts working.
It's a bug, abrt-ccpp.service should be overriding it (in F25; the plan for F26 is to disable abrt-ccpp.service). This is the first I've heard of that happening before. Please file a different bug report as that's not this issue, against abrt I guess (the developers should eventually move it to the right place).

Unless I'm missing something, 3.13.1-225.1.fc25 hasn't done anything to fix this. If I repeat the test case in comment 0, I still get the limit 0 in enforcing mode. Trying the command "sesearch -A -p rlimitinh -s init_t" I I only get an allow rule when transitioning to virtd_t, and one when transitioning to a type I've added in a local module.