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

[Jacobsen, Jasen W.]

Let me make a statement  and see how it plays out: "pkgutil —pkg-info" is useless for OVAL; it should not be relied upon to accurately report system state. At best it can tell you that once upon a time the Installer was run using a particular package, but there is no expectation that the receipt database reflects current system state. There are other more accurate ways to get at the info "--pkg-info" provides.

Would anyone agree or disagree with the above?

As a representative of the language moderator, I don't have an opinion either way. Apple provides a package receipt database and a tool that reports package receipt contents. That seems to be a reasonable capability for OVAL to provide access to. However, if the contents of that receipt database is unreliable (meaning it doesn't reflect system state), then "--pkg-info" should be avoided and other mechanisms should be used to get at the information reported by "--pkg-info", e.g. what version an application is installed. OVAL then should NOT provide access to "--pkg-info" because it is not reliable.

- Jasen.

From: Peter Link <plink53 at mac.com<mailto:plink53 at mac.com>>
Date: Sunday, July 14, 2013 9:08 PM
To: Josh Wisenbaker <dubs at apple.com<mailto:dubs at apple.com>>
Cc: "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>>, "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>>
Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.

update:

The system report is the results of running

>system_profiler

This simple command contains the current status of just about everything system related. The application's reporter files (.spreporter) are found in /System/Library/SystemProfiler. There is a SPApplicationsReporter.spreporter file but the basic operation of running the command system_profiler doesn't appear to run this file while using the GUI does. I'm still looking for more information.

Many of you might want more information on certain files but I suggest looking at the System Profiler to see how much can be found using existing, simple applications.

As for browser plugins, they are normally found in /Library/Internet Plug-Ins making it a simple task to find them.

Excuse me if I'm trying to use the simple way to find things on OSX.


On Jul 14, 2013, at 4:58 PM, Peter Link <plink53 at mac.com<mailto:plink53 at mac.com>> wrote:

OSX provides a very simple method of displaying all applications using About this Mac/More Info as the front end to a System Report. Just need to figure out how the application finds everything. This also finds all devices including printers.


On Jul 12, 2013, at 12:58 PM, Josh Wisenbaker <dubs at apple.com<mailto:dubs at apple.com>> wrote:


On Jul 12, 2013, at 12:19 PM, Jacobsen, Jasen W. <jasenj1 at mitre.org<mailto:jasenj1 at mitre.org>> wrote:

What about non application things like libraries, printer drivers or browser plug-ins?

Off the top of my head you could use simple scripting tools like 'lpinfo -m’ to list all the printer drivers on the system.

I think in most cases things like library versions come when you are looking for a specific version though to validate you are beyond a vulnerable level.


And can you elaborate a little on "use a metadata query and launch services to locate the apps"? Perhaps there are other OS X capabilities that OVAL should make available to system auditors.

Sure. If you are scripting things then you can use the mdfind command to find apps. For example,

mdfind "kMDItemContentTypeTree == 'com.apple.application’"

Is going to instantly find every app on your disks, regardless of where it is stored. You can then loop through them and read the info.plists.

To my mind though it’s easier to do in Objective-C or some other object oriented language than it is to mash all that data around in a bash script. This is some really rough sample stuff code. Note that in the results processing you could also use

NSString *appVersion = [theResult valueForAttribute:(NSString *)kMDItemVersion];

in an effort to not rely on needing to read each plist, but reading the plist lets us cover a use case for if developers don’t fill in both the short version string and the bundle version string.

.....removed script because it made email too long
_______________________________________________
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>



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