Thanks for the feedback, Larry, > - The hardening module I would break out each of these services into > separate modules, so it's more generic. The hardening class itself I > would consider a 'role' that would then include all of these modules > (I have roles exist in the manifest folder and called by site.pp)
I agree with you. One of the reasons why I kept it as a module is due to the other hardening subclasses that I didn't know where to place. But I know know if I actually will change that. See below for details. > - your logindefs class I would consider part of a shadow module that > then has your specific security policy Yes, that makes sense. > - your modules are very centos/RH specific any plans on making them > apply to other OSes? Only upon request/necessity. I generally work on Centos/RedHat, when I'll face the need to run puppet on other distros/os I'll arrange the modules. They already are genrally done in order to support multi os, but actually all the default values are RH based. > - If you are removing packages I would suggest by default installing > the package and then creating an ::absent class to remove or > a ::disable to stop the service but have the module installed. This > also then allows for keeping the package current via that module. I thought about it, but, for packages, I preferred to launch a single removal script (only once) for different reasosn: - It's not mandatory but only suggested to remove those packages. - A plethora of different modules (with actually not much more that the package type) had to be done for most of them - I didn't want to interfere with a possibly large number of modules or possible custom changes by users My point is: the package removal script has to be launched at first puppet run to provide a "clean" system, then the admins should be free to reinstall the removed packages as a deliberate choice and they should do that via puppet possibly with custom classes, without being sticked to the ones provdived with the hardening class (or role). Note that for services I followed a different approach, managing them with puppet types and probably in this case it's better to divide them in different modules and provide service::disable classes. I'll probably fix this and remove the hardening::service class. > I'm not really familiar with EAL4+ CAPP can you tell me more about > this? How is something certified EAL4+ CAPP, and can something be > certified? Stephen John Smoogen has well replied to this. Consider, as written in various parts, that this set of puppet modules is NOT enough to certify an EAL4+ system. I actually suspect that very few systems in the planet can be considered really EAL4+ RBAC certifiable in ongoing operations (does anyone here use fully labeled networking in his systems?? Do sysadmins ALWAYS follow the EAL4+ operations guidelines? ), but that's another point. Best regards, Alessandro Franceschi --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
