Developer meeting II (take 2)
|
|
Hello all,
First, an announcement. The issue with the mailing list has been tracked down, but it looks like we may have to wait for up to two weeks for a fix. The problem seems to be that some messages containing a URL were being blocked. As such, until the matter is resolved, please avoid including URLs in messages. (We don't know if it was just links to Nabble, or if any URL will trigger this.) I will keep you posted. Thank you for your patience. With that out of the way, I would like to resume the developer meetings. I'm re-proposing covering explicit version info in check refs. The writeup is attached. I propose next week for the meeting on Tuesday Oct 6, Wed Oct 7, or Thursday Oct 8 at 3:00 PM eastern time. If you have a preference, please indicate this to me ([hidden email]) by the end of the day on Thursday, Oct 1. I'll send out a final meeting date with call-in information on Friday. Finally, I would also like to announce that there will be an XCCDF workshop at NIST's Security Automation Conference on Thursday, October 29. We will be using that time to clear through a few more, as yet undecided, back issues. I'll send out a writeup of those issues well ahead of the conference so those who are unable to attend can send feedback. I hope to talk to you all next week. Thanks, Charles |
||||||||
ExplicitVersioningInCheckRefs.pdf (91K)
|
|
||||||||
|
|
|
||||||||
|
|
Charles,
> First off, I do not see how the observations you make affect the > proposal to explicitly supply version constraints in check references. > Please let me know if I am missing something. Version constraints like the definition ID are part of the mapping between XCCDF and the checking system. Isolating where changes happen is an OOD way of identifying what should be a separate object. Also, other pieces of the mapping could become global such as the location and version of the OVAL file for example. We do not have a place right now to put global mapping stuff and perhaps we should. Whether it is in a separate file or not is just a detail. > More generally, I think the only defined way to handle the situation > you describe would be for the call to check 456 to contain two check- > export elements, each one for each mapping of the appropriate XCCDF > Value to the appropriate OVAL variable. My understanding of the use of Currently, you are quite right, there is no other solution. This can get tricky though because definitions do not specify input variables in their signature the way most APIs work. The OVAL external variables themselves are global or at least scoped to a file. > check-export is that it applies to one check only. I think it is > actually incorrect to assume that any mapping to an OVAL variable is > global (which one would have to be doing if Rule 456 would > automatically use the variable mapping defined in Rule 123 regardless > of the order of evaluation). In other words, in my understanding check- > export creates a local mapping rather than setting the value of an OVAL > variable. Upon a quick scan of the spec, however, I don't see anything > that explicitly indicates the scope of mappings one way or the other. If we allow for global mappings to be possible, it would make this situation (mapping to globally scoped variables in OVAL) less complicated. There is no reason we should eliminate the ability to have locally scoped variables. Heck, you can technically inline the checking system stuff. Consider this an enhancement request. > Is the above germane to your scenario? I apologize if I completely > missed your point and I'm talking to myself here. I too hope I am making myself clear. Keep asking questions and I will make my best effort to explain myself. > Thanks, > Charles Thank you, Vlad > > >-----Original Message----- > >From: [hidden email] [mailto:[hidden email]] On Behalf Of > >Vladimir Giszpenc > >Sent: Tuesday, September 29, 2009 3:38 PM > >To: Multiple recipients of list > >Subject: RE: Developer meeting II (take 2) > > > > > >Hi Charles et al, > > > >Defining mappings between XCCDF and OVAL in checks poses issues. If > an > >XCCDF rule/check calls an oval definition that has an > >extended_definition (that perhaps has one of its own) which requires > >a(nother) variable being set, the rule/check needs to pass in values > for > >all applicable variables. In our content it was not. > > > >We had > > Rule:123 > > Check > > Pass in variable 123 to definition 123 > >Rule:456 > > Check > > Pass in variable 456 to definition 456 > > > >Our problem was that definition 456 had definition 123 as an extended > >definition. Our bug was that we did not honor the order independence > >that XCCDF is supposed to have and relied on evaluating both rules. > > > > > >This is also a bug in the content that illustrates that maybe we > should > >do things differently. I realize change is a pain, but maybe we > should > >consider extracting the checking system mapping into its own file. > What > >we discuss about versions later will probably support this. We would > >conceivably be able to version this file independently of the > benchmark > >and definitions. > > > >I hope our pain can help others. > > > > > >Respectfully yours, > > > >Vladimir Giszpenc > >DSCI Contractor Supporting > >US Army CERDEC S&TCD IAD Tactical Network Protection Branch > >(732) 532-8959 > > > > > >--------------------------------------------------------------- > > > >To unsubscribe from this mailing list, please send an e-mail to > >[hidden email] with the words "unsubscribe xccdf-dev" in the > >body. You will need to send this from the email account that you > >used to initially subscribe to xccdf-dev. > > > > --------------------------------------------------------------- > > To unsubscribe from this mailing list, please send an e-mail to > [hidden email] with the words "unsubscribe xccdf-dev" in the > body. You will need to send this from the email account that you > used to initially subscribe to xccdf-dev. |
||||||||
|
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
