Puppet users - Apr 2009 - EAL4+ general hardening settings with Puppet

Hallo Puppet Masters,
if you are interested in a puppet-based general hardening setup
following the EAL4+  CAPP guidelines you may find useful what I''ve
reported here: http://www.example42.com/wiki/EalHardening
It has been tested on Centos 5 but should seamlessly apply to RHEL 5
and with minor corrections to RHEL4.
Consider it a work in progress and by no means a complete solution to
achieve a certified EAL4+ system (that involves further steps that
range from installation of a systems to operations).
These hardening settings are a subset of a more general Example(42)
Puppet Infrastructure ( http://www.example42.com ) a set of modules
(in alpha/beta stage) that can be be freely used as as starting point
for a custom Puppet setup.

Feedbacks, improvements and comments are welcomed.

Best regards,
Alessandro Franceschi
Lab42

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Alessandro, great start!

I personally would make these changes to your modules.
- 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)
- your logindefs class I would consider part of a shadow module that  
then has your specific security policy
- your modules are very centos/RH specific any plans on making them  
apply to other OSes?
- 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''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?

-L

--
Larry Ludwig
Reductive Labs


--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Apr 6, 2009 at 11:53 AM, Larry Ludwig <larry@reductivelabs.com>
wrote:
>
> Hi Alessandro, great start!
>
> I personally would make these changes to your modules.
Well the two things I missed were: A documentation outlining all the
steps being done, and that this is more of a hardening document. It
can''t bring a system to EAL3/4/x because the hardware and other parts
need to be evaluated in toto by some ''authority''.  If the Dell
Optiplex 360 is the evaluated model and I use the same configurations
on an IBM Xserver... the system is not EAL4. The hardware would
require evaluation and the software interfacing with it would require
stuff.

I don''t want to come across as a nitpicker, but the difference is
important for people who really need EAL-X. A common problem I have
seen is that someone will find something listed as EAL4 and then
finding out when the auditors show up they didn''t have what they
expected.  I don''t know the best solution to this, but labeling things
as hardening guidelines to help meet CAPP is probably better (and then
a pointer to the document that showed what that meant and what a
person would need to do to know if they comply with
CAPP/LSPP/WXYZ/etc.
> - 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)
> - your logindefs class I would consider part of a shadow module that
> then has your specific security policy
> - your modules are very centos/RH specific any plans on making them
> apply to other OSes?
> - 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.
Ah so thats the best practice for that.
> 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?
CAPP is outlined here
http://www.niap-ccevs.org/cc-scheme/pp/PP_OS_CA_V1.D.cfm The saying is
that CAPP is the new C2 (Orange book) from the old DoD security
guidelines. In reality CAPP is a basic set of configurations that can
be evaluated (eg checkmarked against a known checklist). The other
common ones people use are LSPP and RBAC which are also at the CC
scheme page.

My favorite quote about CAPP is:

The CAPP provides for a level of protection, which is appropriate for
an assumed non-hostile and well-managed user community requiring
protection against threats of inadvertent or casual attempts to breach
the system security. The profile is not intended to be applicable to
circumstances in which protection is required against determined
attempts by hostile and well-funded attackers to breach system
security. The CAPP does not fully address the threats posed by
malicious system development or administrative personnel.
CAPP-conformant products are suitable for use in both commercial and
government environments.

Which can be interpreted as don''t put this box on the internet... but
really means that the various evaluations were meant for a physically
controlled network and may not work in other items. From the newer
niap listings, I would expect that they would consider this ''Basic
Robustness''.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Apr 6, 2009, at 3:08 PM, Stephen John Smoogen wrote:
>
>> - 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)
>> - your logindefs class I would consider part of a shadow module that
>> then has your specific security policy
>> - your modules are very centos/RH specific any plans on making them
>> apply to other OSes?
>> - 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.
>
> Ah so thats the best practice for that.
>>
Keep in mind these are not hardline rules but things I''ve seen work  
for  others.  Also from the module collection I''m creating it seems to
work very well.

-L

--
Larry Ludwig
Reductive Labs


--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hallo Stephen,
> Well the two things I missed were: A documentation outlining all the
> steps being done, and that this is more of a hardening document. It
> can''t bring a system to EAL3/4/x because the hardware and other
parts
> need to be evaluated in toto by some ''authority''.
Yes, a more detailed documentation on the steps done with those puppet
modules (and the ones not done by the modules but still required) is
something I wanted to do, but for time constrains I preferred to write
down the operational stuff, leaving for better days complete docs.
> I don''t want to come across as a nitpicker, but the difference is
> important for people who really need EAL-X. A common problem I have
> seen is that someone will find something listed as EAL4 and then
> finding out when the auditors show up they didn''t have what they
> expected.  I don''t know the best solution to this, but labeling
things
> as hardening guidelines to help meet CAPP is probably better
You''re right in underlining this but that''s what I actually
tried to
express writing:
"Consider it a work in progress and by no means a complete solution to
achieve a certified EAL4+ system (that involves further steps that
range from installation of a systems to operations). "
o, in the linked http://www.example42.com/wiki/EalHardening  page:
"EAL4+ compliance requires much more than what is configured with the
puppet modules provided here: it''s a process that starts from the
hardware choice, the physical location and accessibility of the
servers, their installation, the configuration of the base system
(what is covered here) and the used services and also the day by day
operations on the system."
but maybe you''re right if you consider the title of the post, which
might be confusing under this point of view.

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---