Mac OS X proposed pkginfo OVAL Test.
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/li... 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?
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@g2-inc.com On Thu, Jul 11, 2013 at 9:56 AM, Jacobsen, Jasen W. <jasenj1@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/li... ****
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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple
Great points Shane. Comments inline below. From: Shane Shaffer <shane.shaffer@g2-inc.com<mailto:shane.shaffer@g2-inc.com>> Date: Thursday, July 11, 2013 12:49 PM To: MITRE Employee <jasenj1@mitre.org<mailto:jasenj1@mitre.org>> Cc: "scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>>, "scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org<mailto: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.
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
Someone in the OVAL community mentioned they were trying to use the package receipt plist files to determine if things were installed. "Things" could be applications, patches, libraries, printer drivers, plug-ins, all sorts of things, not just applications. They found directly checking the plist files to be problematic and found pkgutil should be used instead. We (MITRE) developed the referenced extension schema. Mac OS provides an installation receipt capability much like other package managers on other UNIX systems. It seems that OVAL should support checking this system provided audit trail. If the audit trail is unreliable or unsuitable for the purpose, that's another good discussion. - Jasen. From: Peter Link <plink53@mac.com<mailto:plink53@mac.com>> Date: Thursday, July 11, 2013 2:11 PM To: MITRE Employee <jasenj1@mitre.org<mailto:jasenj1@mitre.org>> Cc: "scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>>, "scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org<mailto:oval-developer-list@lists.mitre.org>> Subject: Re: [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test. 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 11:30 AM, "Jacobsen, Jasen W." <jasenj1@mitre.org> wrote:
We (MITRE) developed the referenced extension schema. Mac OS provides an installation receipt capability much like other package managers on other UNIX systems. It seems that OVAL should support checking this system provided audit trail.
If the audit trail is unreliable or unsuitable for the purpose, that's another good discussion.
I'm guessing that a receipt database only works for executable code that was installed through some standard process. Is this the case? A lot of things (like Gatekeeper) were not designed to handle a lot of atypical but by no means not unheard of situations. For example, even if you have Gatekeeper to only run executables signed by a developer, if that app is on a USB thumb drive (or other USB drive) and you double click on it, Gatekeeper won't stop it. Todd
"I'm guessing that a receipt database only works for executable code that was installed through some standard process. Is this the case?" Yes. When the "Installer" is used to install something, then receipts get written. There is lots of software that is installed without using the Installer – e.g. Dragging an application to the Applications folder. - Jasen. From: Todd Heberlein <todd_heberlein@mac.com<mailto:todd_heberlein@mac.com>> Date: Monday, July 15, 2013 9:24 PM To: MITRE Employee <jasenj1@mitre.org<mailto:jasenj1@mitre.org>> Cc: Peter Link <plink53@mac.com<mailto:plink53@mac.com>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org<mailto:oval-developer-list@lists.mitre.org>>, "scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>>, "scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>> Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test. On Jul 11, 2013, at 11:30 AM, "Jacobsen, Jasen W." <jasenj1@mitre.org<mailto:jasenj1@mitre.org>> wrote: We (MITRE) developed the referenced extension schema. Mac OS provides an installation receipt capability much like other package managers on other UNIX systems. It seems that OVAL should support checking this system provided audit trail. If the audit trail is unreliable or unsuitable for the purpose, that's another good discussion. I'm guessing that a receipt database only works for executable code that was installed through some standard process. Is this the case?
True, but if that application is still on the Mac, system profiler will find it and report when it was installed/modified. Isn't this what you want any test to show? On Jul 16, 2013, at 6:08 AM, "Jacobsen, Jasen W." <jasenj1@mitre.org> wrote:
"I'm guessing that a receipt database only works for executable code that was installed through some standard process. Is this the case?"
Yes. When the "Installer" is used to install something, then receipts get written. There is lots of software that is installed without using the Installer – e.g. Dragging an application to the Applications folder.
- Jasen.
From: Todd Heberlein <todd_heberlein@mac.com> Date: Monday, July 15, 2013 9:24 PM To: MITRE Employee <jasenj1@mitre.org> Cc: Peter Link <plink53@mac.com>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org>, "scap-on-apple@lists.macosforge.org" <scap-on-apple@lists.macosforge.org>, "scap-on-apple-dev@lists.macosforge.org" <scap-on-apple-dev@lists.macosforge.org> Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.
On Jul 11, 2013, at 11:30 AM, "Jacobsen, Jasen W." <jasenj1@mitre.org> wrote:
We (MITRE) developed the referenced extension schema. Mac OS provides an installation receipt capability much like other package managers on other UNIX systems. It seems that OVAL should support checking this system provided audit trail.
If the audit trail is unreliable or unsuitable for the purpose, that's another good discussion.
I'm guessing that a receipt database only works for executable code that was installed through some standard process. Is this the case?
_______________________________________________ SCAP-On-Apple-Dev mailing list SCAP-On-Apple-Dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev
Peter and Nancy Link plink53@mac.com plink53@me.com
On Jul 16, 2013, at 6:39 AM, Peter Link <plink53@mac.com> wrote:
True, but if that application is still on the Mac, system profiler will find it and report when it was installed/modified. Isn't this what you want any test to show?
I looked at the output of system_profiler -xml SPApplicationsDataType and it appears to only have .app bundles (e.g., Cocoa applications) and not executable code in general. I couldn't find an argument that would gather all executable code on the system. Anyone know how to search for all executable code on the system (including helper programs)? I am also guessing that it uses data provided by the application itself. That is, the applications are "self reporting". From a security point of view, that seems like an issue to me. There were two more data types I personally found interesting: SPFrameworksDataType (for some of the framework libraries (but again, not libraries in general) and SPExtensionsDataType (for kernel extensions). In addition to whatever security purposes you are looking for, it seems like this would be nice data to help diagnose why one machine in your fleet doesn't behave like the others. Todd PS. I'm not on the Oval mailing list, so if anyone thinks it is appropriate, please forward this email to that list.
I'd like to ask my original question again. What are we trying to find and how does it help define an OVAL test or anything related to the SCAP-on-Apple project? This started with the pkgutil test to figure out what the version and installation date of specific software was. I don't remember seeing anything related to finding every executable (per David Solin posting, Like this? find / -type f -perm +111 -print) on a Windows system only specific ones. I commented on some of the initial tickets posted on http://scap-on-apple.macosforge.org but haven't looked at all of the second batch. I'm going to try and focus my effort on helping get these tickets completed so Shawn can release more. On Jul 20, 2013, at 6:52 PM, Todd Heberlein <todd_heberlein@mac.com> wrote:
On Jul 16, 2013, at 6:39 AM, Peter Link <plink53@mac.com> wrote:
True, but if that application is still on the Mac, system profiler will find it and report when it was installed/modified. Isn't this what you want any test to show?
I looked at the output of
system_profiler -xml SPApplicationsDataType
and it appears to only have .app bundles (e.g., Cocoa applications) and not executable code in general. I couldn't find an argument that would gather all executable code on the system. Anyone know how to search for all executable code on the system (including helper programs)?
I am also guessing that it uses data provided by the application itself. That is, the applications are "self reporting". From a security point of view, that seems like an issue to me.
There were two more data types I personally found interesting: SPFrameworksDataType (for some of the framework libraries (but again, not libraries in general) and SPExtensionsDataType (for kernel extensions).
In addition to whatever security purposes you are looking for, it seems like this would be nice data to help diagnose why one machine in your fleet doesn't behave like the others.
Todd
PS. I'm not on the Oval mailing list, so if anyone thinks it is appropriate, please forward this email to that list.
Peter Link LLNL retired plink53@mac.com
On Thu, Jul 11, 2013 at 1:14 PM, 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 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 G2, Inc. shane.shaffer@g2-inc.com
We have already seen many instances where our patch management solution reports the inventory for all applications including those on backup drives. If I am trying to plumb the inventory to look at vulnerability data I don't really need to see the back-up versions of the now patched MS Office, Adobe Reader, Safari, Firefox etc if they are unlikely to be used. I am all for a full list of all the exectuables but I need to be able to tell between boot volumes and other volumes, especially if they are rarely mounted. On 7/12/13 10:34 AM, Shane Shaffer wrote:
On Thu, Jul 11, 2013 at 1:14 PM, Jacobsen, Jasen W. <jasenj1@mitre.org <mailto:jasenj1@mitre.org>> wrote:
Great points Shane. Comments inline below.
From: Shane Shaffer <shane.shaffer@g2-inc.com <mailto:shane.shaffer@g2-inc.com>> Date: Thursday, July 11, 2013 12:49 PM To: MITRE Employee <jasenj1@mitre.org <mailto:jasenj1@mitre.org>> Cc: "scap-on-apple-dev@lists.macosforge.org <mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org <mailto:scap-on-apple-dev@lists.macosforge.org>>, "scap-on-apple@lists.macosforge.org <mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple@lists.macosforge.org <mailto:scap-on-apple@lists.macosforge.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org <mailto: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 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.
-- ******************************************************** Ron Colvin CISSP, CAP, CEH Certified Security Analyst NASA - Goddard Space Flight Center <ron.colvin@nasa.gov> Direct phone 301-286-2451 NASA Jabber (rdcolvin@im.nasa.gov) AIM rcolvin13 NASA LCS (ronald.d.colvin@nasa.gov) ********************************************************
On Jul 12, 2013, at 10:34 AM, Shane Shaffer <shane.shaffer@g2-inc.com> wrote:
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.
Hi Gang, All of the pkgutil actions are based on the destination volume, so it’s always a good idea to use a target volume. This even goes for generating installer choice manifest files as the install options for packages can vary depending on what is already installed. As for finding installed applications I’ve always found the best option is to use a metadata query and launch services to locate the apps, and then simply read the Info.plist from the bundle to get the version. You could then compare this to the installer DB to find any missing software that was claiming to be installed. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs@apple.com
On Jul 12, 2013, at 10:34 AM, Shane Shaffer <shane.shaffer@g2-inc.com> wrote:
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.
Hi Gang, All of the pkgutil actions are based on the destination volume, so it’s always a good idea to use a target volume. This even goes for generating installer choice manifest files as the install options for packages can vary depending on what is already installed. As for finding installed applications I’ve always found the best option is to use a metadata query and launch services to locate the apps, and then simply read the Info.plist from the bundle to get the version. You could then compare this to the installer DB to find any missing software that was claiming to be installed. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs@apple.com
Excellent. Do you know if /Partition2 has its own Installer receipt DB? Or is the boot volume's DB being used (/var/db/receipts on 10.8)? i.e. Is the receipt for the application installed on Partition2 on the boot volume or the destination volume? The below implies that OVAL would need to know all the volumes available and then check each one. - Jasen. From: Shane Shaffer <shane.shaffer@g2-inc.com<mailto:shane.shaffer@g2-inc.com>> Date: Friday, July 12, 2013 10:34 AM To: MITRE Employee <jasenj1@mitre.org<mailto:jasenj1@mitre.org>> Cc: "scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev@lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>>, "scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple@lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list@lists.mitre.org<mailto:oval-developer-list@lists.mitre.org>> Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test. 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.
There's nothing in /var/db/receipts corresponding to that application when not installed on the root volume. The .bom and .plist can be found in /Volumes/Partition2/Library/Receipts On Fri, Jul 12, 2013 at 12:09 PM, Jacobsen, Jasen W. <jasenj1@mitre.org>wrote:
Excellent. Do you know if /Partition2 has its own Installer receipt DB? Or is the boot volume's DB being used (/var/db/receipts on 10.8)? i.e. Is the receipt for the application installed on Partition2 on the boot volume or the destination volume?
The below implies that OVAL would need to know all the volumes available and then check each one.
- Jasen.
From: Shane Shaffer <shane.shaffer@g2-inc.com> Date: Friday, July 12, 2013 10:34 AM
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-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.
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.
_______________________________________________ SCAP-On-Apple-Dev mailing list SCAP-On-Apple-Dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev
participants (6)
-
Jacobsen, Jasen W.
-
Josh Wisenbaker
-
Peter Link
-
Ron Colvin
-
Shane Shaffer
-
Todd Heberlein