I have been asked by client whether there are any other security restrictions you can apply or not applied during the AMD installation. The person was interested in following CIS Linux security recommendations, asking specifically on umask to utilize (027, 022), or SELinux?
Does AMD installation following any security restrictions? I believe for the SELinux, this is a service that is disabled, or seen as impactful to AMD performance.
Has anyone had experience with this?
Solved! Go to Solution.
SELinux in particular is explicitly not supported even in permissive mode; SELinux inserts several modules between normal host functions even in permissive mode that have caused very difficult to trace problems, and in enforcing mode the AMD simply does not work.
I have worked with multiple customers regarding applying hardening scripts in the past, and can look at the specific version of the scripts you are considering for additional recommendations and caveats.
One in particular I recall off the top of my head are the permissions changes for /var/spool/ and /var/log/ -- after those changes are applied, additionally change /var/log/adlex/ and /var/spool/adlex/ to be recursively owned by the AMD service account credentials (default compuware:compuware) to give the AMD software access to its own log and spool trees.
If you haven't already, check out the DCRUM Security Guide, which contains recommendations for securing and hardening all DCRUM components, including the AMD.
Also check out Preparing Red Hat for AMD Installation without Kickstart and its child pages for information about dependencies and conflicts, particularly if your organisation is proposing to use its own SOE, rather than using the Dynatrace-provided kickstart file.