1 of 1 people found this helpful
open the rule in the template, in the rule conditions it should reference the extended object. then go look in the local template parts for that extended object or the config object dictionary.
thank you for that - I was looking in parts.
My next step is to find out what I have wrong on the server for rule 1.1.1.
In /etc/fstab, /tmp is defined.
# grep " /tmp " /etc/fstab
/dev/mapper/vg_isnmgmvt1-lv_tmp /tmp ext4 defaults 1 2
The extended object of
scriptutil -d "??TARGET.STAGING_DIR??" -h "??TARGET.NAME??"
-s eo_common_code lib_filehandling lib_utils EO-Mount eo_executer
-x -maxdisplay "??MAX_DISPLAY??" -eotimeout "??EO_TIMEOUT??"
-maxinfolines "??MAX_INFO_LINES??" -rscddir "??TARGET.RSCD_DIR??"
-ruleid "1.1.1" -remdirprefix "CIS" -filename "/etc/fstab" -mountpoint "/tmp
is retrieving the incorrect setting of "Open"
Can anyone help on this please.
I won't have CIS content installed for another couple of days (we're upgrading our environment first) so I can't verify/troubleshoot this yet. If you think this is a defect, I would open a Support ticket. They can verify this and open a defect and/or resolve this for you if it's not functioning properly.
thank you for that but I was advised by our BMC contact to raise
it as an open topic here to see if anyone else had encountered the
I don't think there is an issue with the Compliance Template, but
I am trying to figure out what checks the extended objects are running which
might be different in setting/other to the CIS Benchmark commands listed in the CIS document.
A few months ago, I created compliance Templates for RedHat, AIX, Solaris 10&11
Suse and HPUX - These are done in a roundabout way.
Basically, I took every command from the CIS Benchmark docs and created an
executable script for each OS to capture results in a temporary output file.
A Component Template was then created to check each result output.
Within BL, I then had the folowing batch job for each OS.
1. A File Deploy job to push the script to the relevant server(s).
- Post commands within the file deploy job to check that the script was
valid using cksum.
- Execute the script on the server to capture output to an output file.
2. Discovery job in case new servers had been added.
3. Compliance job to check the results from the output file.
As a random example: 1.1.18
Within the script we have the following.. as taken from CIS Benchmark.
## 1.1.18 Disable Mounting of cramfs Filesystems
## ## Expected result. install /bin/true and null
check1=`/sbin/modprobe -n -v cramfs`
check2=`/sbin/lsmod | grep cramfs`
echo 1.1.18a $check1 >> $OUTPUT
echo 1.1.18b $check2 >> $OUTPUT
The Compliance Template then checks that 1.1.18a exists within the
output file and that value1 for 1.1.18a is install and value2 is /bin/true.
If I manually go onto the server and run all the commands from the CIS
Benchmark, I know the server I am using to test is close to 100% compliant.
However when I run the BMC Template, my compliance is down to 50%, so my
main query is what is different in the extended objects supplied with the
template as opposed to the CIS Benchmark.
It might be that I need some setting/other changed.
1 of 1 people found this helpful
So the way these EOs are written is probably a bit convoluted but there is some reasoning behind it. a lot of the compliance policies have checks like "no world writeable files" or "xxx should have these permissions" or something like that. because it's cheaper to run the OS's find command rather than via nsh or a file object we created a script framework to gather a bunch of info from the target once, leave it on the target and then process those results, rather than running a whole sequence of finds or whatever for each check like that. so the command is below:
scriptutil -d "??TARGET.STAGING_DIR??" -h "??TARGET.NAME??" -s eo_common_code lib_filehandling lib_utils EO-Mount eo_executer -x -maxdisplay "??MAX_DISPLAY??" -eotimeout "??EO_TIMEOUT??" -maxinfolines "??MAX_INFO_LINES??" -rscddir "??TARGET.RSCD_DIR??" -ruleid "1.1.1" -remdirprefix "CIS" -filename "/etc/fstab" -mountpoint "/tmp
so scriptutil just handles copying scripts over to the target server and executing them and passing args. so there are five scripts executed here - 'eo_common_code' 'lib_filehandling' 'lib_utils' 'EO-Mount' and 'eo_executer'. in that order. then everything after the -x are args to the script. so you can find those files in the NSH/share/sensors directory on the appservers, and they may have an OS-specific file extension which is where scriptutil will figure out which one to run on the target. so in one of those scripts there will probably be a section to handle the fstab file and look for '/tmp' and do some evaluation based on the 1.1.1 rule.
thanks again for the pointers.
In the scripts I created, to cater for the multiple find commands, all non compliant files/dirs were trapped in one find command and output went to a temp file. This temp file was then interrogatted for each instance of SUID/SGID/World
writable etc non compliance...
This removed the need for 8-12 find runs within a template...in the same way as BMC are trying to cater for in the
supplied Template... There was never going to be an easy way to do this I think.
I am just going through the scripts to map out what is returned against what is expected.
Thanks again for the help.