shupaza: Server Hardening via Cfengine

About Development CVS

The shupaza project is an experiment to prove the ability for the Cfengine community to create a dialog for sharing configurations. The idea is to create a common method and architecture to communicate. In other words is it possible for the community to create an architecture with in the defintion of a set of cfengine configuration files, that allows us to share. The experiment will be conducted first by attempting to translate the server hardnening part of the Solaris Security Toolkit (SST) a.k.a. JASS. We are picking a known set of scripts that already idenitifies "what" needs to be done. So this should eliminate an problems deciding what should be done. All that remains is focusing on the implementation. After the successful translation of the SST project from shell to Cfengine, the project will focus on creating definitions for hardering other platforms such as Linux. Ideally we reach the goal of being able to plugin the cfengine scripts into an existing installation of Cfengine, or make it run standalone. It should also support the updates. It should also be able to turn on and off what is hardened based on defined classes.

My initial thoughts are to code up a quick architecture that gives us the ability to support this configuration both stand alone and as a plugin. Of course the plugin will require the individual to adhere to a few rules (of which I don't know right now). The one thing I do know about SST is it has the ability to audit and rollback. But the audit is sort of useless with Cfengine, with Cfengine you want to be hardened end of story. With the rollback it is all or nothing. What I want is the ability to turn the hardening on and off again. SST also has the ability to preform local overrides of certain values. This should also be supported. Once the architecture is up I will make the code available then, stub out all the items that need to be harden, and wait for people to submit code for inclusion. Please email me with any initial thoughts.

Convention

• Naming -- Every variable and class should be made up with the word jass. This will prevent any pontent namespace conflicts when the Cfengine JASS code is included inside an existing cfengine installation. Try to stick with the same variables use as much as possible
• Functions -- If possible all the functions should be implemented as methods, this gives us the freedom of a seperate actionsequence for each function we implement. It also single sources the functionality incase it changes in the JASS codebase. The resulting code will also be clean, seperating form from function. The function names should still have the same name for clarity, even though a disable_conf_file function will support enabling as well. Don't worry about checking to see if the parameters are empty, cfengine requires the parameters at compile time.
• Rollback -- The scripts should support the ability to move from disabling to reenabling to disabling without issue
• Logging -- Everything should be logged through alerts, every action should be chained with a success class until the final action is reached. The final action should define a success class that is tied to an appropriate alert. If there a failure occurs then a failure class should trigger an appropritate failure alert. Once the enabling or disabling has occured, it should continue to check, but not log anything.

• create_timestamp -- The function does a while look that checks to make sure the timestamp file it creates doesn't already exists. I am not certain why they do this other than the edge case two are running at the same time. But this seems unlikely, and with Cfengine locking I am not to worried about this. So we just inline a timestamp.
• move_a_file -- is not implemented, it makes a call to add_to_manifest which is not needed, so the abstraction is not required

Coming Soon.