________________________________________
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