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

David Solin david at joval.org
Thu Jul 11 11:16:53 PDT 2013 

I think what's generally desirable to know, is whether a particular 
version of a particular application is installed on a machine.  If that 
application/version has a known vulnerability, that makes it easy to 
test for the vulnerability.

Alternatively, there is the inventory use-case in OVAL: I want to know 
what's installed on my machines.

So, the question is, is this command/database of packages good for 
either or both of these uses?  (If not, I'm curious to know what it's 
good for, or why it exists at all).

Regards,
--David Solin

On 7/11/2013 1:11 PM, Peter Link wrote:
> 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 at mitre.org 
> <mailto:jasenj1 at mitre.org>> wrote:
>
>> 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.
>>
>>
>> _______________________________________________
>> SCAP-On-Apple mailing list
>> SCAP-On-Apple at lists.macosforge.org 
>> <mailto:SCAP-On-Apple at lists.macosforge.org>
>> https://lists.macosforge.org/mailman/listinfo/scap-on-apple
>
> Peter Link
> LLNL retired
> plink53 at mac.com <mailto:plink53 at mac.com>
>
>
>
>
>
> _______________________________________________
> SCAP-On-Apple-Dev mailing list
> SCAP-On-Apple-Dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev


-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

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

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