hardening-script-el6
hardening-script-el6 copied to clipboard
fcaviggia
uninstalling the rpm reverts system hardening
This may not be an issue and perhaps is intended behavior. When you uninstall the stig-fix rpm it appears to revert the changes to the system. Is there a way to "cleanup" and remove the rpm and scripts from a system after deployment without reverting the hardening of the system?
rpm --erase --noscripts | --nopre --nopost --nopreun --nopostun Whatever you don't want to run.
Sorry for the late reply, I was away on my honeymoon. I created the 'checkpoint.sh' script, which gets aliased to 'stig-fix-checkpoint', to checkpoint the system - otherwise it gets reverted to whatever was backed up during running the script initially.
Okay, here's some options - I can use the checkpoint.sh to overwrite the items in backup and restore them to the system upon removal or just leave it be. The RPM puts everything back to what was in backup upon removal of the RPM from the system.
Why would the pre/post uninstall scriptlets undo something which was not done in the pre/post install scriplets?
The hardening-script package also violates other RPM packaging rules for no good reason that I can see. For example, the package doesn't actually depend on screen, ntp, etc. Satisfying the CCEs that each of those packages be installed should be done the same way other CCE are satisfied: via scripts run by the user which in turn execute e.g. yum install -y logwatch scrub aide vlock screen ntp openswan rsyslog
Those packages you mention are required by the DISA STIG, by adding them in as dependencies the packages are automatically installed with yum... if you don't want those packages installed feel free to remove them from the spec file and run make rpm to get the desired result for your builds.
Sorry, I don't think I was clear - I'm not suggesting that those packages should not be installed; I'm suggesting that the mechanism for installing those packages should be different.
I created the RPM that way so it would pull them in during an install, I disagree that it violates RPM packaging rules because RPM was designed with that kind of functionality in mind. Check out:
https://github.com/fcaviggia/hardening-script-el6-kickstart
The vision was to create the RPMs for your systems (web, database, file, etc.) upload to an RHN Satellite and distribute the configurations via RPM, ensuring that the systems receiving it pulled down the required packages in the process. The idea to checkpoint a configuration, build a new RPM, and distribute was just an ease of use idea and to keep the original files from replacing a system that was already configured and running by uninstalling the RPM.
The reason these scripts still exists is mainly for historical purposes - I've redirected my hardening efforts to the SCAP Security Guide as the "official" hardening tool for RHEL here with these two projects:
https://github.com/RedHatGov/ssg-el6-kickstart
https://github.com/OpenSCAP/scap-security-guide