[SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.
shane.shaffer at g2-inc.com
Fri Jul 12 07:34:52 PDT 2013
On Thu, Jul 11, 2013 at 1:14 PM, Jacobsen, Jasen W. <jasenj1 at mitre.org>wrote:
> Great points Shane. Comments inline below.
> From: Shane Shaffer <shane.shaffer at g2-inc.com>
> Date: Thursday, July 11, 2013 12:49 PM
> To: MITRE Employee <jasenj1 at mitre.org>
> Cc: "scap-on-apple-dev at lists.macosforge.org" <
> scap-on-apple-dev at lists.macosforge.org>, "
> scap-on-apple at lists.macosforge.org" <scap-on-apple at lists.macosforge.org>,
> oval-developer-list OVAL Developer List/Closed Public Discussion <
> 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 have a system with two volumes, the boot volume and one named Partition2.
I installed an application on Partition2. If I run "pkgutil --pkgs" that
package is not listed. If I run "pkgutil --pkgs --volume
/Volumes/Partition2" then it is listed. So it appears that querying the
receipt database is volume specific. If I subsequently install the same
application on the root volume, then it shows up as you'd expect via
"pkgutil --pkgs" and there appears to be no link between the two installs.
I would think that just checking the boot volume would be akin to just
checking C:\Program Files on Windows - overwhelming probability of being
the location, but not good enough.
> 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.
I think may be very useful, but we need to understand the limitations and
add whatever capabilities are needed to let us to deal with those
limitations (if possible) so in the end we aren't left still unable to
accurately determine what is on the system.
shane.shaffer at g2-inc.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SCAP-On-Apple-Dev