FWIW, I should add that we like actually these three tests for MacOS, and it seemed to us that there was general agreement at developer days that these made good sense. So, in this case, perhaps we should interpret silence as consent! (And my point about the IOS schema is not to demean it, but merely to illustrate that having something, even if it's terribly limited, is infinitely more useful than having nothing at all!) On 8/29/2013 10:12 AM, David Solin wrote:
If you build it, they will come.
Seriously. Look at the Cisco IOS schema. It's a useless bunch of garbage, defined a decade ago, and Cisco has managed to leverage it into the basis of very useful vulnerability content!
If we add nothing, OSX support will never get anywhere.
On 8/29/2013 10:03 AM, Jacobsen, Jasen W. wrote:
There has been no follow-up or discussion of the items below. At this point it is very unlikely the below proposals will make it into OVAL 5.11.
- Jasen.
From: <Jacobsen>, MITRE Employee <jasenj1@mitre.org <mailto:jasenj1@mitre.org>> Date: Monday, August 12, 2013 3:05 PM To: "scap-on-apple-dev@lists.macosforge.org <mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org <mailto:scap-on-apple-dev@lists.macosforge.org>> Subject: [SCAP-On-Apple-Dev] Three proposed OVAL tests for OS X.
As part of the OVAL moderator team, I'm looking for feedback from the OS X domain experts on whether the below proposals make sense. Are they useful? Do they follow OS X best practices? I'm trying to get a feel of whether I'm on the right track, and solicit guidance on the general design.
1 System Profile Test This test would be based on system_profiler. The system_profiler "DataType" argument would be specified as part of the OVAL definition, to direct what should be collected. An Xpath expression would be used to navigate the XML result of system_profiler. This Xpath would be required to resolve to a simple string value, not a node-tree. For those familiar with XML programming, a "value-of" operation would be performed on the result of the Xpath. This test would provide great flexibility in using system_profiler to query the system state. However, the trade-off is that the Xpath expressions would likely be fairly complicated. Below is an Xpath that could be applied to the SPApplicationsDataType results to get the version of TextEdit installed. /plist/array[1]/dict[1]/key[.='_items']/following-sibling::array[1]/dict/key[.='_name']/following-sibling::*[1][.='TextEdit']/following-sibling::key[.='version']/following-sibling::*[1] A bit intimidating if you don't know Xpath well, but fairly straight forward if you do.
2 Application Test A common use case of OVAL is to determine if an application is installed, and what version of an application is installed. This test would be based on the output of system_profiler SPApplicationsDataType. It would provide simple, direct access to the various fields provided by SPApplicationsDataType. Using this test, an OVAL definition could directly evaluate: name -- the application's name app_store -- whether the app came from the app store has64bitintelcode -- whether the app has 64-bit Intel Code info -- a text field last_modified -- when the app was last modified path -- the path to the application's package runtime_environment -- the CPU architecture the app is compiled for version -- the version Using this test, one could craft OVAL definitions that answered questions such as "is application MS Word with version less than 10.2 installed".
Note: The community may find that there are other commonly used system_profiler data types that could also benefit from having a dedicated test.
3 Preference Test This test would be based on the CFPreferences API. Specifically, the function CFPreferencesCopyAppValue(). The OVAL definition would specify: application_id -- the application's id, e.g. com.foo.appName key -- the preference to retrieve value -- the value of the preference to be evaluated. Note: preferences allows any "property list" type in preferences; these are CFArray, CFDictionary, CFNumber, CFBoolean, CFData, and CFString. It is unclear how the CFArray and CFDictionary types should be handled by OVAL. Perhaps the result of CFPreferencesCopyAppValue() could be returned as XML and an Xpath expression could be applied to get to the value to be evaluated?
Note also that OVAL currently has a plist test that is designed to read preferences out of plist files -- such as those found in ~/Library/Preferences. This preference test is proposed because it will return the true preference value; the actual value may be different than the value found in the plist file based on managed preferences (if I understand things correctly).
At DevDays it was suggested that trackers be created on the SCAP-on-Apple site for OVAL issues. If the above look reasonable, could someone give me some pointers on creating good trackers?
- Jasen.
_______________________________________________ SCAP-On-Apple-Dev mailing list SCAP-On-Apple-Dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev
--
jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>
-- jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>