________________________________________
> From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> Mon, 7 Nov 2016 17:45:42 +0000
>
> Hi Radzy.
>
> Are you trying to bundle everything into one XCCDF? If so,
> you may be making the problem harder than it needs to be.
Hi Brent
No, I'm not trying anything yet. I'm just looking ahead to what I
expect my next task will be, and trying to make sure I understand
enough background information to be able to proceed when I get
to it.
I'll interpret your comment as a recommendation that I plan on
using multiple XCCDFs. And probably multiple OVALs as well.
I do want to minimize the amount of cut-n-paste duplication. So it
would be nice if some of the minor differences can be handled by
a single file with selectable options. If that won't work, or
if it's too difficult, then I'll go ahead with the cut-n-paste.
But I think it's worth spending some time to avoid it.
Enjoy!
-- radzy
> -----Original Message-----
> From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com]
> Sent: Friday, November 4, 2016 4:52 PM
> To: scap-security-guide(a)lists.fedorahosted.org
> Subject: RE: VMs, containers vs. bare-metal machines in SSG
>
>
> ________________________________________
> > -----Original Message-----
> > From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] Friday,
> > October 21, 2016 1:16 PM
> > > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> As opposed to
> > > writing one XCCDF, why not write one XCCDF per point of interest
> > > (inside the container of interest, inside the OS but outside the
> > > container of interest, ...) - until upstream standards address
> > > Origin, Point (in SpaceTime), Frame of Reference, ... for a
> > > cyber-physical assembly?
> >
> > When I start working on our container environment, I expect I need to
> > write custom XCCDF and custom OVAL for some of the checks.
> > Some of the management may be done in the container, but I expect most
> > to be done in the underlying host. So paths may be different, which
> > would lead to either more complex OVAL with parameterization, or
> > duplication of the OVAL content.
> >
> > And as implied elsewhere, the XCCDF needs to be modified to indicate
> > the correct information for the environment.
> >
> > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> Wed, 2 Nov 2016
> > 19:52:29 +0000 (edited) Hi Radzy.
> > Assuming a strawman consisting of: one OS(i.e. apps, libraries,
> > OSxContainer-Interface, etc.); and one container(i.e. app, libraries,
> > ContainerxOS-Interface, etc.).
> >
> > There is
> > one XCCDF for the OS (baseline)
> > one XCCDF for the container (delta)
> > one XCCDF for OS + container (net)
> > one XCCDF for OS union net (max)
> > one XCCDF for max - (OS intersection net ) (min)
> >
> > The last XCCDF is:
> > one XCCDF for OS intersection net (min)
> >
> > Whereas functionality at risk of eclipse is
> > max - (OS intersection net )
>
> Hi Brent
>
> Right. Thanks for the enumeration.
>
> I still need to look into two questions:
>
> - Can I use docker to support what I need to do ? Since OpenSCAP
> does have some kind of docker support built-in, and I haven't
> looked at it, this might be less work. But I need to look
> into it.
>
> - Can I use some kind of a prefix variable to minimize the amount
> of duplication. Then I could have a profile for the OS and one
> for each container, and specify a procedure where both profiles
> are run with independent oscap commands. Then some XCCDF for
> the other cases not covered by those two, possibly in a third
> oscap invocation..
>
> And of course, there's always the possibility that some aspects of both will be useful. And the likelyhood that I'll need to do something custom.
>
> Enjoy!
>
> -- radzy