Jasen, What are you trying to achieve? Is your goal a test that logs whether a specific application has (ever) been installed? I'm trying to understand why this would be needed. Knowing whether a patch has been installed was used for Windows systems (although I'm not sure that actually means anything was fixed) but using the existence of an application being installed (or attempted to be) doesn't mean it actually patched something or should be used as validation that something was fixed. It also doesn't necessarily mean the patch or application was completely installed. On Jul 11, 2013, at 10:14 AM, "Jacobsen, Jasen W." <jasenj1@mitre.org> wrote:
Great points Shane. Comments inline below.
From: Shane Shaffer <shane.shaffer@g2-inc.com> Date: Thursday, July 11, 2013 12:49 PM To: MITRE Employee <jasenj1@mitre.org> Cc: "scap-on-apple-dev@lists.macosforge.org" <scap-on-apple-dev@lists.macosforge.org>, "scap-on-apple@lists.macosforge.org" <scap-on-apple@lists.macosforge.org>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@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.
_______________________________________________ SCAP-On-Apple mailing list SCAP-On-Apple@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple
Peter Link LLNL retired plink53@mac.com