July 2013 - SCAP-On-Apple-Dev - lists.macosforge.org

Developing OVAL Inventory Tests for Apple Platforms.
by Jacobsen, Jasen W. 29 Jul '13

29 Jul '13

(I'm attempting to reset the conversation and move forward from what went on in the pkginfo discussion.) One of the typical uses for OVAL (http://oval.mitre.org) is to determine whether a particular version of a particular software package is installed. E.g. Is Firefox version 22.0 installed? These tests are typically used to determine if a machine is susceptible to particular CVEs. See http://oval.mitre.org/repository/data/ViewDefinition?id=oval%3aorg.mitre.ov…. On Windows systems, the registry is typically consulted to see if an application is installed and what version it is. On Red Hat Linux systems, the Red Hat Package Manager (RPM) is checked (see http://oval.mitre.org/repository/data/ViewItem?id=oval:org.mitre.oval:tst:3…) If you check the similar inventory definitions in the OVAL Repository for OS X you will notice a few things (http://oval.mitre.org/repository/data/SearchDefinitionAdv?class=2&family=2) : 1. There are very few items compared to Windows or Linux. 2. They all check for the existence of a particular file, whether it be in the package receipt directory (/private/var/db/receipts) or the /Applications directory. Based on the discussion concerning the pkginfo test, the above approach of checking for the existence of certain files is at best not a best practice, and at worst dangerously wrong. During the pkginfo test discussion, it was mentioned that "system_profiler SPApplicationsDataType" could be used from the command line, and Josh shared some Objective-C code that does a metadata query. I want to be careful when developing the OVAL constructs not to dictate the implementation. E.g. Issuing "system_profiler SPApplicationDataType" and then using Xpath to examine the XML might work, but an "application_test" that you hand an application name and get back metadata similar to what system_profiler provides may make more sense. On Windows, there is not a "regedit_test", there's a "registry_test". Under the covers, "application_test" could use system_profiler or API calls to return the desired stuff. And how the information is retrieved could depend on many things – is the evaluation being done directly on the box? Is a central scanner being used that connects remotely to a box? Is MDM being used? If we go down the path of "systemprofiler_test" that limits our options quite heavily. OTOH, system_profiler seems to be very flexible and gives access to many types of information in an "Apple approved" way. Perhaps implementing a general system_profiler based test quickly will be a good starting point and from there we can move on to better, more specialized tests. (Similar to how there is a textfilecontent test, but there is now a proposal for an INI test as working with INI files as raw text files is extremely cumbersome.) - Jasen.

2 2

Mac OS X - system_profiler test?
by Jacobsen, Jasen W. 26 Jul '13

26 Jul '13

At Developer Days during my pkginfo test presentation it was mentioned that system_profiler can be used to get an accurate list of the applications that are currently installed. It was also mentioned that system_profiler can output XML in plist form. The suggestion was made that an OVAL test based on system_profiler could be created and XPath could be used to find the information being queried. Based on that, I took a little time to see what the XPath might look like for such a test. $ system_profiler -xml SPApplicationsDataType > applications.plist The above tells system profiler to list all the applications it knows about, format the output as XML (plist), and write it to a file. Here's a snippet of the output: <plist version="1.0"> <array> <dict> <key>_SPCommandLineArguments</key> <array> <string>/usr/sbin/system_profiler</string> <string>-xml</string> <string>SPApplicationsDataType</string> </array> <key>_SPCompletionInterval</key> <real>0.54004198312759399</real> <key>_dataType</key> <string>SPApplicationsDataType</string> <key>_detailLevel</key> <integer>1</integer> <key>_items</key> <array> <dict> <key>_name</key> <string>TextEdit</string> <key>app_store</key> <string>no</string> <key>has64BitIntelCode</key> <string>yes</string> <key>lastModified</key> <date>2012-09-02T10:52:45Z</date> <key>path</key> <string>/Applications/TextEdit.app</string> <key>runtime_environment</key> <string>arch_x86</string> <key>version</key> <string>1.8</string> </dict> … (lots of dict elements, each representing an application) One XPath that could be used to answer the question "What version of TextEdit is installed?" is: /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] That XPath can be broken down into sections as follows: /plist/array[1]/dict[1]/key[.='_items'] - Find the "_items" /following-sibling::array[1]/dict - Find to the "dict" elements that contain each application's info. key[.='_name']/following-sibling::*[1][.='TextEdit'] - Find "_name" "TextEdit". /following-sibling::key[.='version']/following-sibling::*[1] - Find the "version" value. Run against the above, all that will return "1.8". Does that seem reasonable? Are XPaths of that complexity typically used in OVAL? Or does this fall into the territory of trying to treat INI files as text files? - Jasen.

1 0

Mac OS X proposed pkginfo OVAL Test.
by Jacobsen, Jasen W. 24 Jul '13

24 Jul '13

The Mac OS Installer program writes receipt files to a database after installing software. This receipt information includes version, install time, install volume, install location, and any groups the installed package may be a part of. This receipt information is precisely the type of data OVAL is frequently used to examine. This sort of information is already collected in other component schemas using the dpkginfo, rmpinfo, and other tests. The Apple provided way to get at this information is the "pkgutil" command line tool. It is proposed to create an OVAL test and supporting items based on the "pkgutil --pkg-info" command output. A detailed paper describing this test can be found at https://github.com/OVALProject/Sandbox/blob/master/resources/x-macos-pkginf…<https://github.com/jasenj1/Sandbox/blob/master/resources/x-macos-pkginfo/Ma…> The proposed schema can be viewed at https://github.com/OVALProject/Sandbox/blob/master/x-macos-pkginfo.xsd<https://github.com/jasenj1/Sandbox/blob/master/x-macos-pkginfo.xsd> The Linux rpminfo test is very similar to what is being proposed and provides a good model. http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/l… The structure of the proposed test is as follows: pkginfo_object package_id – The ID of the package to examine (volume? - pkgutil allows a different volume to be specified. It's unclear if this would be needed or useful.) pkginfo_state & pkginfo_item package_id – The ID of the package examined version – The version of the package install_time – When the package was installed. Given in seconds since the UNIX epoch. volume – The volume the package is installed on. location – The path where the package was installed, if specified at time of install. group – The group(s) the package is a part of. Element repeats for multiple groups. (filepath?– file(s) associated with the package. See question below for discussion of this.) Questions: Exactly what portions of the information provided by --pkg-info are needed for OVAL? e.g. Volume, location, group, filepath? Is there a public API to get the information provided by pkgutil? Or is calling the command the only way to get it? The rpminfo test has a "filepaths" behavior that will collect all of the files associated with a package. pkgutil supports the same function using the "-- files" command. Should this be added to the pkginfo test?

8 35

Mac's Audit Data (slightly OT)
by Todd Heberlein 23 Jul '13

23 Jul '13

During the discussion started last week on trying to find out what programs, libraries, plug-ins, etc. were installed on a system to determine if a system is vulnerable, someone asked about using audit data (I think to validate the accuracy of data collected about programs). Virtually everywhere I go, no one seems to know that they can do with audit data, which isn't surprising since there aren't exactly a lot of books or training courses on audit data as there are for network monitoring. I put together this 7:38 min video on some of the information Apple's BSM audit data can provide. Should you be leveraging Apple's BSM audit system? http://www.netsq.com/Podcasts/Data/2013/AuditIntro/ If scap-on-apple will include audit system configuration, at some point we should have a discussion about what types of questions you want to ask of that data. Todd

2 1