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.
-----Original Message----- From: Radzykewycz, T (Radzy) [mailto:[email protected]] Sent: Friday, November 4, 2016 4:52 PM To: [email protected] Subject: RE: VMs, containers vs. bare-metal machines in SSG ________________________________________ > -----Original Message----- > From: Radzykewycz, T (Radzy) [mailto:[email protected]] Friday, > October 21, 2016 1:16 PM > > From: Brent Kimberley <[email protected]> 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 <[email protected]> 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 _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message. _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
