Here's a script I put together to implement FIPS at https://access.redhat.com/discussions/3487481
FIPS is a U.S. government computer security standard used to approve cryptographic modules. It is (just) one small portion among many topics when dealing with security mitigations.
Thanks for the link. The script looks interesting, but I noticed that it doesn't work if I have a customised kernel on RHEL 7.
What I mean by that is that the script looks for an "el7" string to determine the RHEL version, but if my compiled kernel doesn't have it, the script exits. I understand that the majority of people will be using the kernel that comes with the OS so this is not a problem for them, but it would be reasonable to add some additional steps for RHEL version identification to make it a bit more portable.
Lisenet,
Red Hat doesn't support custom compiled RHEL kernels. However, it looks like RJ is either the author or maintainer of the script as on the linked discussion he asks for feedback. However, instead of that logic trying to RH's policies around custom kernel support, the logic is more to identify a RHEL7 system vs RHEL6 vs RHEL5 et al.
I would suggest that the author of the script move from 'uname -a | grep el7' and instead something more like:
head -n1 /etc/redhat-release | grep [0-9] | cut -d'.' -f1| rev | cut -c 1
I'm sure someone could also come up wiht a like a 1 line awk+sed script to do this as well, but I'm a shell guy. The grep from the middle could be cut out if one knows that the 1st line of the /etc/redhat-release file was not modified. Maybe a bit better would be to check the file for modification before horking with it for getting decision data. Like:
if [ $(rpm -Vf /etc/redhat-release | grep redhat-release | grep 5 &>/dev/null) ]
then
echo "ERROR: /etc/redhat-release has been modified, NOT DEFAULT"
exit
else
$rhel_maj_vers = $(head -n1 /etc/redhat-release | cut -d'.' -f1| rev | cut -c 1)
fi
That would account for a kernel version without el{num} and would also check to see if someone had modified /etc/redhat-release before making important decisions based on the data.
-STM
@Scottsupport wasn't a concern in this case. You could use CentOS for example.
I wouldn't remove the "uname -a" part. It does its job as long as you assume that the kernel is the mainline one. What I would do instead is to add some extra steps (e.g. rpm or redhat-release) to check for the OS version if the "uname -a" section fails. There are several places information like this can be gathered from.
@Lisenet Why have 2 checks when one will do?
Using uname has sketched me out since I ran into a production issue 7 years ago where a vendor, in their rpm scripting had: rm -rf /lib/modules/`uname -r`/kernel/..... which removed a different kernel's module instead of the one that was installed by the RPM. My personal approach has been to use data that doesn't change, and verify that it has not changed prior to making decisions on it. Trust, but Verify.
-STM
@Scott The /etc/redhat-release method works if you make an assumption that the content of the file has not been modified. It might not work otherwise. That's why I suggested to a have more than one check.
Hi Lisenet,
Just curious, with your custom kernel, what is the output of "uname -r"? I'd like to consider this.
I'm probably going to take a different approach. I posted a reply earlier regarding my not using /etc/redhat-release because I want something less "fragile" due to the numerous (numerous enough, that is) experiences where admins/and others edit /etc/redhat-release for a variety of reasons.
Thanks
RJ
@RJ I've just copied the output from one of our dev servers (yes, I am aware that 4.2 is EOL. )
$ uname -r 4.2.6-dev
There is no reason why we cannot add the "el7" part to the name, but it's not there by default. You get the idea.
Thanks everyone for the feedback. (I'm the creater/maintainer of that script) I did not use a conditional test of /etc/redhat-release because I wanted something "less fragile" because there are admins that will on occasion change the contents of /etc/redhat-release to make some third party software work (just one example of several I have seen). That being said, there's other ways for me to achieve this without having to use "el7" or /etc/redhat-release.
Scott (STM) makes a good point regarding 'uname -r' however, I'm not dealing with the entire kernel version, just using it to rule if it is or is not RHEL 7. That being said, I'm probably going to pursue a different method.
I'll pursue some other method for that portion. I've seen the fragile nature of /etc/redhat-release enough in (at least) the various customers I support and didn't want to have the script bail due to that. Like STM's input too, I've found that to be the mantra to follow especially with fragile files in the environments I support.
Thanks much
RJ
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.