(MODULES-4093) Tighten SELinux permissions on persistent files

(MODULES-4093) Tighten SELinux permissions on persistent files

RHEL7's /usr/libexec/iptables/iptables.init creates the /etc/sysconfig/iptables
file with the wrong selinux parameters, causing spurious changes on the next
run:

    [root@ns57zjx0zb7s0b5 ~]# rm -f /etc/sysconfig/iptables
    [root@ns57zjx0zb7s0b5 ~]# ls -la /etc/sysconfig/iptables
    ls: cannot access /etc/sysconfig/iptables: No such file or directory
    [root@ns57zjx0zb7s0b5 ~]# iptables -A INPUT --source 8.8.8.8 -j REJECT
    [root@ns57zjx0zb7s0b5 ~]# /usr/libexec/iptables/iptables.init save
    iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
    [root@ns57zjx0zb7s0b5 ~]# ls -la /etc/sysconfig/iptables
    -rw-------. 1 root root 259 Nov 19 06:02 /etc/sysconfig/iptables
    [root@ns57zjx0zb7s0b5 ~]# /opt/puppetlabs/bin/puppet apply --verbose selinux.pp
    Notice: Compiled catalog for ns57zjx0zb7s0b5.delivery.puppetlabs.net in environment production in 0.08 seconds
    Info: Applying configuration version '1479564151'
    Notice: /Stage[main]/Main/File[/etc/sysconfig/iptables]/seluser: seluser changed 'unconfined_u' to 'system_u'
    Notice: /Stage[main]/Main/File[/etc/sysconfig/iptables]/seltype: seltype changed 'etc_t' to 'system_conf_t'
    Notice: Applied catalog in 0.03 seconds
    [root@ns57zjx0zb7s0b5 ~]# X Error of failed request:  RenderBadPicture (invalid Picture parameter)

To fix this, this patch changes the order in which puppet checks the resources.
Instead of managing the persistence file before the service, now we manage the
file after all firewall rules. The firewall provider persists the rules to disk
causing the /etc/sysconfig/iptables file to be created. Managing its
permissions afterwards leads to one-run idempotency.

To see why this change is legal, consider the possible initial states for a
moment:

* fresh install: the /etc/sysconfig/iptables file does not exist
  in the previous implementation, puppet would create it empty with the correct
  permissions, only to have it overwritten when persisting the firewall rules
* fixed point: the /etc/sysconfig/iptables file already exists with the correct
  permissions, and nothing has changed. The order of resource application is
  irrelevant
* a firewall rule has changed: the firewall type will persist the rules
  changing the permissions to a invalid state, puppet will fix it in the same
  agent run.
* the /etc/sysconfig/iptables file is in an invalid state: this might be the
  most annoying case. In the original version, puppet would have fixed the file
  before touching the service. Now the service could arguably fail to start if
  the permissions are really bad. Puppet will still fix the issue, and start
  the service on the next run, so I do not consider this to be a big problem.