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

New OVAL tests for MacOSX
by David Solin 16 Aug '14

16 Aug '14

(Note: cross-posted to two mailing lists) jOVAL.org has just published OVAL schemas for nine new MacOS test types: * authorizationdb_test - provides access to plist information stored in the authorization database * corestorage_test - provides access to core storage information * gatekeeper_test - provides access to Gatekeeper information * keychain_test - provides access to keychain settings * launchd_test - enumerates launchd-initiated agents/daemons * rlimit_test - provides access to launchd resource limits * softwareupdate_test - provides access to softwareupdate list/schedule * systemprofiler_test - provides access to plist-format data from the system_profiler * systemsetup_test - provides access to system setup information See: https://github.com/joval/Sandbox/commit/827c2dec9a9c3db51860c288994f452381b… Note, I think the keychain_test is potentially problematic, because desktop access is required in order to read another user's keychain (so someone can enter the keychain's password in the dialog box that pops up) -- meaning it can only be implemented by a host-based user-driven assessment tool. Anyway, any feedback (from the Apple community in particular) would be appreciated. Best regards, --David Solin -- jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>

1 0

New OVAL tests for MacOSX
by David Solin 16 Aug '14

16 Aug '14

(Note: cross-posted to two mailing lists) jOVAL.org has just published OVAL schemas for nine new MacOS test types: * authorizationdb_test - provides access to plist information stored in the authorization database * corestorage_test - provides access to core storage information * gatekeeper_test - provides access to Gatekeeper information * keychain_test - provides access to keychain settings * launchd_test - enumerates launchd-initiated agents/daemons * rlimit_test - provides access to launchd resource limits * softwareupdate_test - provides access to softwareupdate list/schedule * systemprofiler_test - provides access to plist-format data from the system_profiler * systemsetup_test - provides access to system setup information See: https://github.com/joval/Sandbox/commit/827c2dec9a9c3db51860c288994f452381b… Note, I think the keychain_test is potentially problematic, because desktop access is required in order to read another user's keychain (so someone can enter the keychain's password in the dialog box that pops up) -- meaning it can only be implemented by a host-based user-driven assessment tool. Anyway, any feedback (from the Apple community in particular) would be appreciated. Best regards, --David Solin -- jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>

1 0

Re: [SCAP-On-Apple-Dev] [Fed-Talk] What happened with SCAP-on-Apple?
by David Solin 03 Jun '14

03 Jun '14

jOVAL is currently soliciting for beta testers for automated STIG evaluation on Apple OSX. Those interested should contact jOVAL via http://joval.org/contact for more information. [NB: cross-posting to the scap-on-apple list] Regards, --David Solin On 2/10/2014 4:56 PM, Colvin, Ron (GSFC-700.0)[VALADOR INC] wrote: > For those on the list using CIS or looking for security guidance > rather than compliance the Benchmark for 10.8 was released last week. > We are hoping to get 10.9 out in a couple months, depending on how > many changes there are from 10.8. > > https://benchmarks.cisecurity.org/downloads/show-single/?file=osx108.100 > > Mobile > > On Feb 10, 2014, at 5:40 PM, "John Oliver" <john.n.oliver.ctr(a)navy.mil > <mailto:john.n.oliver.ctr@navy.mil>> wrote: > >> It looks like that project is languishing. This makes me sad. >> >> I attended (virtually) the OSD Apple Engineering Coalition >> <https://dodaec.osd.mil/> kickoff last week, and, coincidentally, >> just found out about and volunteered for a working group to address >> enterprise management of Macs at SSC. One of the obvious issues we >> have with Macs on a government network is STIGs, the rapid release >> and die-off schedule for OSX, and the three years it takes DISA to >> release a STIG (BTW: I believe we can expect a STIG for Mountain Lion >> maybe in a month or so?) >> >> Red Hat addressed this issue with their own open source SCAP Security >> Guide <https://fedorahosted.org/scap-security-guide/> project. >> That's the official upstream for STIGs for Red Hat now, and they can >> get it done in about a year. Something like this would be a >> tremendous resource for Apple and for those of us who use Apple products. >> >> I hope we can light a fire and help SCAP-on-Apple to succeed! >> >> Anyone who's interested in DoDAEC – I can forward on some info to >> anyone with a CAC who works on a DoD program. They created a trifold >> but it weighs in at 12MB so I won't be attaching it :-) >> >> >> -- >> >> John Oliver | SAIC >> >> Defense & Maritime Solutions >> >> Surveillance and Reconnaissance Solutions Division >> >> SPAWAR Systems Center Pacific | Code 53223 >> >> Sr. Systems Administrator >> >> Bldg 600 | Room 428N >> >> Office: (619) 553-9567 >> >> john.n.oliver(a)saic.com <mailto:john.n.oliver@saic.com> >> >> joliver(a)spawar.navy.smil.mil <mailto:joliver@spawar.navy.smil.mil> >> >> DCO: john.oliver8(a)chat.dco.dod.mil >> <mailto:john.oliver8@chat.dco.dod.mil> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Fed-talk mailing list (Fed-talk(a)lists.apple.com >> <mailto:Fed-talk@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/fed-talk/ron.colvin%40nasa.gov >> >> This email sent to ron.colvin(a)nasa.gov <mailto:ron.colvin@nasa.gov> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Fed-talk mailing list (Fed-talk(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/fed-talk/david%40joval.org > > This email sent to david(a)joval.org -- jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>

1 0

[MacOSForge.org] Servers will be down for scheduled maintenance - TUE 11 MAR 2014 8AM-12PM PST
by Shawn Geddis 10 Mar '14

10 Mar '14

SmartCardServices & SCAP-On-Apple Participants, Scheduled maintenance on ALL Mac OS Forge Servers will be taking place on TUE 11 MAR 2014 8AM-12PM PST. It is scheduled to start at 8AM PST and the activity is expected to take about four hours or more resulting in shutdown until at least 12PM PST. All affected servers will be going through a change in IP address. DNS changes to the domain will be made and its propagation to the Public domains will take approximately 30 Mins to an hour. When maintenance begins, all MacOSForge systems are expected to stop functioning. We very much appreciate your participation and hope the scheduled downtime does not negatively impact your efforts. If you have any questions, comments or otherwise, please drop a line to the projects Admin account: SmartCardServices Admin scs-admin(a)macosforge.org SCAP Admin scap-admin(a)macosforge.org - Shawn _______________________________________________________________________ Shawn Geddis Enterprise Security Consulting Engineer, Apple (geddis(a)apple.com) SCAP-On-Apple Project/Dev Lead: (SCAP-On-Apple.MacOSForge.Org) SmartCardServices Project/Dev Lead: (SmartCardServices.MacOSForge.Org) _______________________________________________________________________

1 0

Three proposed OVAL tests for OS X.
by Jacobsen, Jasen W. 29 Aug '13

29 Aug '13

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.

2 3

ticket #53, iOS6
by Peter Link 12 Aug '13

12 Aug '13

http://scap-on-apple.macosforge.org/trac/ticket/53 This is the first iOS ticket I've seen. Are we working on OSX-only a combination of both or would it be better to create a separate iOS ticket list? Peter Link LLNL retired plink53(a)mac.com

1 0

tickets 42-52, file should not have an extended ACL
by Peter Link 12 Aug '13

12 Aug '13

http://scap-on-apple.macosforge.org/trac/report/8 I wasn't looking at the tickets, only the Wiki page, so didn't realize there's been lots of progress made. Regarding tickets 42-52, I've seen something similar to identifying whether a program/application/executable/file has a particular setting in other OS testing. I presume these were identified by Shawn as files that shouldn't have an extended ACL configured for some reason. I am guessing the person who argued against requiring these tests is Jeffrey Blank, who stated there are thousands of files that could be tested with no real reason for testing them. OSX has the ability to verify and repair disk permissions using Disk Utility. This process goes through the entire disk, comparing file (and maybe ACL) permissions against a file containing the correct permissions. It includes non-Apple files so it gets updated when non-Apple applications are installed. Having all files properly configured is extremely important since it's an obvious way for malware to attack a system, therefore, I feel file settings are critical to a properly configured Mac. How it's done is up for discussion. 1. Do we create a CCE entry for every check Disk Utility performs when verifying file permissions? 2. Do we create a CCE entry for the Disk Utility file permissions verification process and leave it at that? How are people intending to use the information gathered by the ACL checks? Would we need a separate OVAL test for each ACL check listed in tickets 42-52 or could we have one CCE and one OVAL test that simply runs: diskutil verifyVolume MountPoint|DiskIdentifier|DeviceNode This will return lots of information while running (when using the terminal) but the expected result would be: The volume MacFusHD appears to be OK (had fun replacing my 2009 iMac's hard drive with an OWC SSD and larger HD, then creating a Fusion drive) Would this result, or one that says it needs repairing, be enough to satisfy everyone's desire to validate the proper settings for all OSX program files? Peter Link LLNL retired plink53(a)mac.com

1 0

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