coming soon: consistency checking scripts

Steve Grubb sgrubb at redhat.com
Fri Mar 16 16:47:28 UTC 2012


On Thursday, March 15, 2012 01:59:25 PM Spencer R. Shimko wrote:
> >Then slap on a begining section that defines a
> >few global settings that anaconda needs and then we have a kickstart
> >script.
> 
> Now you lost me.  Why is anaconda part and parcel to the end solution?  Or
> is this for integration into Satellite?

No. There are 2 kinds of system. The ones running and the ones needing to be 
installed. The ones needing to be installed can be kickstarted into the correct 
configuration from the beginning. Then its easy for a content developer to go 
through the guide, make some choices, save, and then run the oscap tool to make 
the fix script. Then you just add some preample stuff and you have a golden master 
for deployments.

We use kickstart for many things, like the livecd creator and the appliance 
creator. So, its really the ubiquitous file for system creation on RHEL. I'd like 
to see as many uses enabled as possible. I'm also thinking of this guide being 
used for other security purposes than government security. Like PCI-DSS where 
they may be making a minimal system to be a database server.

 
> >Its
> >possible to do this because the basic commands are present. But if you
> >get too
> >far from that using augeas, for example, then the command might not exist
> >prior
> >to install. I think busybox has the commands that are using during
> >kickstart.
> 
> Is this based on the assumption that the fixes will be applied in a spec
> %post and not a ks %post?  

No. I'd have to see it work. But in the appliance situation they want a minimal 
system. So, the common denominator is shell and busybox.


> If so, why is that desirable? Is there an issue
> with doing this in %post as opposed to anaconda "proper"?
> 
> >> I guess the real question here is if we should ignore the fact that it
> >> isn't in a SCAP standard and push the Puppet-based remediation content
> >> into SSG.  I would really prefer this approach but I completely
> >>
> >>understand
> >>
> >> if the SSG community doesn't want to start cramming non-SCAP content in
> >> SSG's git repo.
> >
> >I'd like to think both can be done. But maybe not. Managing a system by
> >puppet
> >is very different than use cases I am considering. If you ran a scan and
> >found
> >something wrong, wouldn't you need to remediate the repository and push
> >the
> >changes to the system being scanned?
> 
> Ah is this coming from the thought of using Puppet Master (puppet server)?

Yeah.

-Steve


More information about the scap-security-guide mailing list