[SCAP-On-Apple-Dev] Three proposed OVAL tests for OS X.

Thu Aug 29 08:20:06 PDT 2013

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 at mitre.org 
>> <mailto:jasenj1 at mitre.org>>
>> Date: Monday, August 12, 2013 3:05 PM
>> To: "scap-on-apple-dev at lists.macosforge.org 
>> <mailto:scap-on-apple-dev at lists.macosforge.org>" 
>> <scap-on-apple-dev at lists.macosforge.org 
>> <mailto:scap-on-apple-dev at 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 at 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/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/scap-on-apple-dev/attachments/20130829/22c91774/attachment.html>