Description of problem:
I booted into a F30 KDE Plasma spin installation that was fully updated with updates-testing enabled. I logged into Plasma 5.15.5 from sddm 0.18.1. I ran scap-workbench with the PCI-DSS v3 Control Baseline for Fedora profile. I generated a remediation bash script in scap-workbench which I ran in konsole with sudo. There were two rules about failed logins which hadn't passed. 

Set Deny For Failed Password Attempts
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny
To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:
add the following line immediately before the pam_unix.so statement in the AUTH section:
auth required pam_faillock.so preauth silent deny=6 unlock_time=1800 fail_interval=900
add the following line immediately after the pam_unix.so statement in the AUTH section:
auth [default=die] pam_faillock.so authfail deny=6 unlock_time=1800 fail_interval=900
add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
account required pam_faillock.so

Set Lockout Time for Failed Password Attempts
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time
To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:
add the following line immediately before the pam_unix.so statement in the AUTH section:
auth required pam_faillock.so preauth silent deny=6 unlock_time=1800 fail_interval=900
add the following line immediately after the pam_unix.so statement in the AUTH section:
auth [default=die] pam_faillock.so authfail deny=6 unlock_time=1800 fail_interval=900
add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
account required pam_faillock.so

The remediation script changed settings about failed logins as described above. I rebooted. I saw a denial of systemd writing to /var/run/faillock each of two times that I logged into Plasma on X from sddm. 
type=AVC msg=audit(1561266957.146:283): avc:  denied  { write } for  pid=1171 comm="(systemd)" name="faillock" dev="tmpfs" ino=26855 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0

The first time the Plasma didn't seem to finish loading properly as it was stuck on the splash screen. After I shutdown the system, I logged into Plasma which started fine but with the same denial. 

I ran the following to allow the denial of systemd writing to faillock from VT2
sudo ausearch -c '(systemd)' --raw | audit2allow -M my-systemd
sudo semodule -X 300 -i my-systemd.pp
sudo systemctl restart sddm
I logged into Plasma on X from sddm which froze again. sudo ausearch -m AVC -ts today showed the following denial
type=AVC msg=audit(1561271692.725:495): avc:  denied  { add_name } for  pid=4243 comm="(systemd)" name="sddm" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0

I repeated the steps above twice, and each time Plasma on X got stuck on the splash screen. The following two denials were shown.
type=AVC msg=audit(1561271929.865:547): avc:  denied  { create } for  pid=4680 comm="(systemd)" name="sddm" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=0
type=AVC msg=audit(1561272064.759:593): avc:  denied  { setattr } for  pid=4973 comm="(systemd)" name="sddm" dev="tmpfs" ino=86576 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=0

The xembedsniproxy segmentation faults happened each time I repeated the steps above in VT2 and then logged into Plasma on X which was stuck on the splash screen. The segmentation fault in FdoSelectionManager initEv of
of xembedsniproxy seemed to happen because the Plasma program it was waiting on didn't respond which led to a null pointer dereference if I remember correctly.

I didn't see more denials after that. The my-systemd.te module had the following rules.
allow init_t faillog_t:dir { add_name write };
allow init_t faillog_t:file { create setattr };

I reported the systemd denials at https://bugzilla.redhat.com/show_bug.cgi?id=1723132



Version-Release number of selected component:
plasma-workspace-5.15.5-1.fc30

Additional info:
reporter:       libreport-2.10.1
backtrace_rating: 4
cmdline:        /usr/bin/xembedsniproxy
crash_function: FdoSelectionManager::init
executable:     /usr/bin/xembedsniproxy
journald_cursor: s=75fbb14c78ac44d8b68b0a626f5e1722;i=a52b;b=3bb28375081744a0bec99f0de4b4e1ea;m=133743e10;t=58bf7fc80fe33;x=16a6c708334fbaa8
kernel:         5.1.12-300.fc30.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 FdoSelectionManager::init at /usr/src/debug/plasma-workspace-5.15.5-1.fc30.x86_64/xembed-sni-proxy/fdoselectionmanager.cpp:69
 #1 QtPrivate::QSlotObjectBase::call at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394
 #2 QSingleShotTimer::timerEvent at kernel/qtimer.cpp:318
 #3 QObject::event at kernel/qobject.cpp:1282
 #4 doNotify at ../../include/QtCore/../../src/corelib/kernel/qobject.h:142
 #5 QCoreApplication::notifyInternal2 at kernel/qcoreapplication.cpp:1084
 #6 QTimerInfoList::activateTimers at kernel/qtimerinfo_unix.cpp:643
 #7 timerSourceDispatch at kernel/qeventdispatcher_glib.cpp:182
 #11 g_main_context_iteration at ../glib/gmain.c:3988
 #12 QEventDispatcherGlib::processEvents at kernel/qeventdispatcher_glib.cpp:422