Physical hardware access has to top the potential risk list. All DAC and MAC protections can be avoided by booting from CD, which puts anything and everything at risk.
Mitigation: Limit access to computer machine rooms. Lock racks and strictly control access. Routinely review access lists. Consider encrypting partitions that contain sensitive data, or even entire disks if possible.
Some users may not have machine room access, but have permission to boot the system. This gives them the ability to change boot parameters, or even boot a different kernel. One such boot parameter can disable SELinux and make files accessible to unauthorized users.
Mitigation: Make sure that only trusted administrators receive console access. Log console activity to see who uses the console and what they are doing. If possible use a remote logging service like Splunk, which can be configured to send alerts.
By default most SELinux Policies apply the following context to users:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
The unconfined_t type is an extremely powerful domain, SELinux prevents very little. So unless the user is restricted by DAC, he can do basically anything.
Mitigation: Direct file access can be prevented by creating a new type (say csi_compartment_t) and not assigning it any attributes that the unconfined_t domain has privileges towards. Develop an extensive test harness. Never make policy changes until they have been thoroughly tested.
An important privilege that some users have is that they can modify SELinux policy, or disable SELinux altogether. SELinux policy is complicated and changes demands great care. These users could also use their privileges to subvert security.
Mitigation: In order to prevent this, we have to make sure that users can either not manipulate SELinux policy, or make sure users do not get access to privileged domains. Use tools like Ansible to detect and remove unapproved policy changes.
Another privilege that needs to be watched is the ability to change file context. For instance, if the ca_private_key_t type were not declared properly, the type might be assigned an attribute that other domains have privileges against. Consider the file_type attribute, granted to file types.
# seinfo -tca_private_key_t -x
ca_private_key_t
file_type
The moment a domain has been granted read access to file_type files, then it has read access to the ca_private_key_t type as well.
Mitigation: While designing a policy change, make sure that all granted permissions are accounted for. Develop an extensive test harness, and never apply changes until they have been thoroughly tested.
Mitigation: Protect device files just as you would regular files.
Some processes or users might have access to authentication files like /etc/password and /etc/shadow; or the PAM files in /etc/pam.d/*, or the PAM security modules themselves. These file can be manipulated to gain unauthorized access.
Mitigation: Protect these sensitive files with SELinux. Don't allow remote root login. Incorporate the excellent logging capabilities available to sudo to monitor root activities.
Most would agree that backups contain the same sensitive data contained on the system itself, and should be protected with the same vigilance. However, high performance computing clusters normally include redundancy throughout. So the question should be asked, "Are backups necessary and advisable. After all, they increase the risk of a data spill.
Mitigation: If backups are deemed necessary, control physical access to backup systems, and if possible use encryption.