fapolicyd should gracefully start despite errors in fapolicyd.conf

[jasongodev]

Issue: When fapolicyd fails to parse its config file, sees some errors in trust database, or just any kind of error, systemd will fail to load fapolicyd and will still continue loading the system. Worst, this failure is not obvious unless logs are always read or there are other layers of automation meant to capture this event. The usual hardening recommendations in openscap and RHEL's documentation does not tackle this.

Steps to reproduce: Just mess the contents of /etc/fapolicyd/fapolicyd.conf. Or set the value "permissive = x" instead of a number.

Suggestions:

• fapolicyd should gracefully start using the strongest default configuration if the config file can not be parsed. For variables that have invalid values, the strongest default value should be assumed. Log this event so admins can see.
• If not for fapolicyd, create an option for systemd to stop the loading process when fapolicyd fails to load. This will prevent a compromised system from continuing loading the system.

[stevegrubb]

This is kind of how daemons get your attention...failing to start. For example:

$ systemctl --no-pager is-active sshd
active
$ sed -i "/^#MaxSessions/s/#MaxSessions 10/MaxSessions X/" /etc/ssh/sshd_config
$ systemctl --no-pager restart sshd
Job for sshd.service failed because the control process exited with error code.
See "systemctl status sshd.service" and "journalctl -xeu sshd.service" for details.

Starting with the strongest setting might also be bad because you might not have IMA setup. You might have a loophole for a certain account to do things and now it's blocked. There might be some simple things that could be done to limp along. Such as a typo in the cache size. We could pick a default and keep going. But what if you never notice it and correct it? A problem with the trust db should not stop a boot, it should reassemble a new version and keep going.

Also, there is this:
$ fapolicyd-cli --check-config
Daemon config is OK