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.