[SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.

[Jacobsen, Jasen W.]

Great points Shane. Comments inline below.

From: Shane Shaffer <shane.shaffer at g2-inc.com<mailto:shane.shaffer at g2-inc.com>>
Date: Thursday, July 11, 2013 12:49 PM
To: MITRE Employee <jasenj1 at mitre.org<mailto:jasenj1 at mitre.org>>
Cc: "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>>, "scap-on-apple at lists.macosforge.org<mailto:scap-on-apple at lists.macosforge.org>" <scap-on-apple at lists.macosforge.org<mailto:scap-on-apple at lists.macosforge.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list at lists.mitre.org<mailto:oval-developer-list at lists.mitre.org>>
Subject: Re: [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.

Since the target volume can often be specified during installation, it seems that we would need to specify the volume. However that is going to require the ability to enumerate the volumes via OVAL, and an existing way to do that isn't jumping out at me.

Jasen: I think there are two "volumes" in play here. One is the command option "--volume" which tells pkgutil which volume's receipt database to check (I'm pretty sure). Second is the volume reported by "--pkg-info" which is the volume the package is installed on. So something installed to a different volume could have its receipt info on the boot volume. Would OVAL need/want to check the receipt database on multiple volumes? Or is the boot volume sufficient? Clarification from Apple or someone else who really knows this would be helpful.

I wonder how reliable this test will be for accurately detecting installed software given that the database typically(?) is not updated when a package is uninstalled. If the software came with an uninstaller and that was used then it hopefully remove the data, but if the user just moves a .app package to the trash the data reported by pkgutil remains. Of course on any platform there's a possibility of false positives when an application is removed by means that don't remove the artifacts used to detect the installation (e.g. deleting a Windows app without running the uninstaller, leaving behind the registry data used to detect it). This false positive can often be avoided by methods like doublechecking that the application files are actually present where the installation info says it was installed. This is rarely done though, most likely because the author assumes that the user uninstalled the software the recommended way (that fully cleaned up after itself), and a false positive for not uninstalling it the right way is a fair punishment. Here it seems like it may be more problematic because just deleting the .app is what Apple recommends for non-App Store apps, and that doesn't fully clean up after itself, making false positives much more likely. I guess that means we'll need to take the extra step to verify that the files are present, which means we'll need to get the --files info back from this test so we know where to look. It seems like the location element would be sufficient, but if that isn't always populated (and in my brief testing that appears to be the case), then it appears --files may be the way to go.

Jasen: Excellent points. Knowing whether/ensuring the receipt database reflects actual system state does seem to be a big issue. However, do these validation issues negate the need/usefulness of a test that checks the system provided receipt artifacts? As of now, OVAL has no way to examine these – the plist test is inadequate as Apple explicitly says not to do that. I believe OVAL needs this test, but crafting content to use it wisely is another issue.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/scap-on-apple/attachments/20130711/1a592090/attachment.html>