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

Shane Shaffer shane.shaffer at g2-inc.com
Thu Jul 11 09:49:28 PDT 2013


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.

(Incidentally, the diskutil_state documentation has a minor error, starting
with "The package_state element..." - I was looking to see if the volumes
could be enumerated via a diskutil_object and noticed that)

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.

Shane Shaffer
G2, Inc.
shane.shaffer at g2-inc.com


On Thu, Jul 11, 2013 at 9:56 AM, Jacobsen, Jasen W. <jasenj1 at mitre.org>wrote:

>   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-pkginfo/Mac%20OS%20X%20pkginfo%20Test.docx<https://github.com/jasenj1/Sandbox/blob/master/resources/x-macos-pkginfo/Mac%20OS%20X%20pkginfo%20Test.docx>
> ****
>
>
>
> 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/linux-definitions-schema.html#rpminfo_test
> ****
>
>
>
> 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?
>
> _______________________________________________
> SCAP-On-Apple mailing list
> SCAP-On-Apple at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/scap-on-apple
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/scap-on-apple-dev/attachments/20130711/d63ccd55/attachment-0001.html>


More information about the SCAP-On-Apple-Dev mailing list