Security Assessment Tools





Sometimes you want to check different aspects of a distribution for security problems. This can be anything from file permissions to correctness of code. This page is a collection of those tools. Depending on what information the tool has to access, it may need to be run as root.

* File permission test This will scan a file system to see that it complies with the 2011 Unix STIG recommendations.

* RPM RELRO and PIE flag policy test rpm-chksec This will take an rpm name as input and verify each ELF file to see if its compiled with the intended flags to most effectively use PIE and RELRO. Green is good, Orange could use work but is acceptable, and Red needs fixing. It has a mode --all that is the equivalent of using rpm -qa and feeding the packages to it. In this mode it will only give a summary result for the package. To find which files don't comply, re-run using just the package name.

* Search for ELF files not dropping supplemental groups find-nodrop-groups This will scan a whole file system to see if a program makes calls to change UID and GID without also calling setgroups or initgroups.

* RPM search for ELF files not dropping supplemental groups rpm-drop-groups Same as above, but takes an rpm name instead.

* Bad chroot test find-chroot This script scans the whole file system looking for ELF files that calls chroot(2) that also do not include a call to chdir. Programs that fail to do this do not have the cwd inside the chroot. This means the app can escape the protection that was intended.

* Bad chroot python test find-chroot-py This test is like the one above except it examines python scripts for the same problem.

* Find programs with an executable stack find-execstack This program scans the whole file system for ELF programs that have marked the stack as being executable. This means that if the program has another vulnerablity such as stack buffer overflow, any code the attacker places there is executable. Any program found must be fixed.

* Find hidden executables find-hidden-exec This program scans the whole file system looking for excutables that are hidden. Anything found must be investigated since its highly unusual for executables to be hidden.

* Shell script error test find-sh4errors This program scans the whole file system looking for shell scripts. It then does a sh -n on the script which causes bash to parse the file to see if there are any mistakes. This test can take a while to run, but is worthwhile as who wants a broken shell script?

* SE Linux unlabeled devices selinux-check-devices This script checks the /dev directory to see if there are any devices that are not correctly labeled. Anything found by this test should be reported so that selinux policy can be fixed. This test is very hardware specific, so to be effective a lot of people with different hardware should run this test each upstream kernel version release.

* SE Linux unconfined process test selinux-ls-unconfined This script scans the running processes and looks for anything labeled with initrc_t or inetd. These both mean that there are daemons that do not have policy and are therefore running unconfined. These should be reported as SE Linux policy problems. Because it checks currently running daemons, the more you have running, the better the test is.

* Find shell scripts with well known tmp files find-sh4tmp This script scans the whole filesystem to check if shell scripts are using well known tmp file names instead of obscure ones created by something like mktemp. This script can occassionally mis-identify a well known name and if you find a case where the script is giving a false positive, please let me know.

* Find ELF files with well known tmp files find-elf4tmp This script scans the whole file system for ELF files using /tmp. When it finds this, it also looks to see if any of the known good random name generator functions is called by looking at the symbol table. If not, it will output the string. This test is still under development but is useful as is.

* This script lib-bin-check will check all installed library packages to see if an application is also part of the package. The relationship to security is that the SHA256 hash check will fail if a 32 bit version overwrites it. Also, the less binaries on a system, the more secure it is by virtue of removing the chance for an exploitable bug.