Re: [SCAP-On-Apple] [SCAP-On-Apple-Dev] Mac OS X proposed pkginfo OVAL Test.
What about non application things like libraries, printer drivers or browser plug-ins? 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. - Jasen. From: Josh Wisenbaker <dubs@apple.com<mailto:dubs@apple.com>> Date: Friday, July 12, 2013 11:44 AM To: Shane Shaffer <shane.shaffer@g2-inc.com<mailto:shane.shaffer@g2-inc.com>> Cc: MITRE Employee <jasenj1@mitre.org<mailto:jasenj1@mitre.org>>, 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. 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.
On Jul 12, 2013, at 12:19 PM, Jacobsen, Jasen W. <jasenj1@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. Starting the search: - (void)findApps { //Start our timer self.startDate = [NSDate timeIntervalSinceReferenceDate]; // Create the metadata query instance. The metadataSearch @property is // declared as retain self.metadataSearch=[[NSMetadataQuery alloc] init]; // Register the notifications for the completion updates [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(queryDidUpdate:) name:NSMetadataQueryDidUpdateNotification object:self.metadataSearch]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(initalGatherComplete:) name:NSMetadataQueryDidFinishGatheringNotification object:self.metadataSearch]; // Configure the search predicate to find all apps using the com.apple.application UTI NSPredicate *searchPredicate; searchPredicate=[NSPredicate predicateWithFormat:@"kMDItemContentTypeTree == 'com.apple.application'"]; [self.metadataSearch setPredicate:searchPredicate]; // Set the search scope to local disks NSArray *searchScopes; searchScopes=@[NSMetadataQueryLocalComputerScope]; [self.metadataSearch setSearchScopes:searchScopes]; // Begin the asynchronous query [self.metadataSearch startQuery]; } Then processing the results: // Method invoked when the initial query gathering is completed - (void)initalGatherComplete:sender; { // Stop the query, the single pass is completed. [self.metadataSearch stopQuery]; // Iterate the results and find our info. NSUInteger i=0; for (i=0; i < [self.metadataSearch resultCount]; i++) { NSMetadataItem *theResult = [self.metadataSearch resultAtIndex:i]; NSString *appPath = [theResult valueForAttribute:(NSString *)kMDItemPath]; // Use launch services to retrieve info and filter out invisibles and aliases // Launch Services is CF so we need to bridge to a CFURLRef CFURLRef appURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (__bridge CFStringRef)appPath, kCFURLPOSIXPathStyle, YES); // Create our LSItemInfoRecord LSItemInfoRecord itemInfoRecord; // Pass in our CFURLRef and filter out invisibles and aliases LSCopyItemInfoForURL(appURL, kLSRequestBasicFlagsOnly | kLSRequestAppTypeFlags, &itemInfoRecord); //We don't need the appURL anymore so set it free CFRelease(appURL); if ((itemInfoRecord.flags & kLSItemInfoIsApplication) && !(itemInfoRecord.flags & kLSItemInfoIsInvisible) && !(itemInfoRecord.flags & kLSItemInfoIsAliasFile)) { // Make some strings to hold our data NSString *nameString = nil, *versionString = nil; // Make sure it really is an app bundle if (itemInfoRecord.flags & kLSItemInfoIsContainer) { // Get info for app bundles // Load in the Info.plist and read the keys NSDictionary *infoDictionary = [NSDictionary dictionaryWithContentsOfFile: [appPath stringByAppendingPathComponent: @"/Contents/Info.plist"]]; nameString = infoDictionary[@"CFBundleName"]; versionString = infoDictionary[@"CFBundleShortVersionString"]; if (!versionString) { versionString = infoDictionary[@"CFBundleVersion"]; } //Add our info to a mutable dict. NSDictionary *dict = @{@"appName": nameString, @"appVersion": versionString}; } } } // Remove the notifications to clean up after ourselves. // Also release the metadataQuery. // When the Query is removed the query results are also lost. [[NSNotificationCenter defaultCenter] removeObserver:self name:NSMetadataQueryDidUpdateNotification object:self.metadataSearch]; [[NSNotificationCenter defaultCenter] removeObserver:self name:NSMetadataQueryDidFinishGatheringNotification object:self.metadataSearch]; self.metadataSearch=nil; //Stop our timer and figure how long that took NSTimeInterval totalTime; self.stopDate = [NSDate timeIntervalSinceReferenceDate]; self.theText = [NSString stringWithFormat:@"App search took: %.4f seconds", (totalTime = self.stopDate - self.startDate)]; }
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@apple.com> wrote:
On Jul 12, 2013, at 12:19 PM, Jacobsen, Jasen W. <jasenj1@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple
Peter and Nancy Link plink53@mac.com plink53@me.com
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@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@apple.com> wrote:
On Jul 12, 2013, at 12:19 PM, Jacobsen, Jasen W. <jasenj1@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/scap-on-apple
Peter Link LLNL retired plink53@mac.com
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@mac.com<mailto:plink53@mac.com>> Date: Sunday, July 14, 2013 9:08 PM To: Josh Wisenbaker <dubs@apple.com<mailto:dubs@apple.com>> Cc: "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. 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@mac.com<mailto:plink53@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@apple.com<mailto:dubs@apple.com>> wrote: On Jul 12, 2013, at 12:19 PM, Jacobsen, Jasen W. <jasenj1@mitre.org<mailto:jasenj1@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@lists.macosforge.org<mailto:SCAP-On-Apple@lists.macosforge.org> https://lists.macosforge.org/mailman/listinfo/scap-on-apple Peter Link LLNL retired plink53@mac.com<mailto:plink53@mac.com>
Remember too that you can pass categories to system_profiler to control what info it returns. It also can give you your output in XML format. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs@apple.com On Jul 14, 2013, at 9:08 PM, Peter Link <plink53@mac.com> wrote:
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@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.
Jasen and Josh, does this help? system_profiler -xml SPApplicationsDataType > ~/Desktop/SPlist gives complete listing of all applications found on the Mac, including drivers and anything application related. Output is XML file stored wherever you want it. typical entry for printer driver. Shouldn't be a problem extracting whatever information you want from it. <dict> <key>_name</key> <string>HP LaserJet 400 M401dn (F739D8)</string> <key>app_store</key> <string>no</string> <key>has64BitIntelCode</key> <string>yes</string> <key>lastModified</key> <date>2012-10-22T03:04:58Z</date> <key>path</key> <string>/Users/link/Library/Printers/HP LaserJet 400 M401dn (F739D8).app</string> <key>runtime_environment</key> <string>arch_x86</string> <key>version</key> <string>8.3</string> </dict> disclaimer: I'm not a programmer, I'm more a facilitator who can sometimes find answers for things. I spent 18 years managing a Mac-based publication system and an additional 8 years trying to make sure our OS configurations met DOE requirements. On Jul 15, 2013, at 8:33 AM, Josh Wisenbaker <dubs@apple.com> wrote:
Remember too that you can pass categories to system_profiler to control what info it returns.
It also can give you your output in XML format.
Josh
-- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs@apple.com
On Jul 14, 2013, at 9:08 PM, Peter Link <plink53@mac.com> wrote:
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@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.
Peter Link LLNL retired plink53@mac.com
On Jul 15, 2013, at 10:50 AM, Peter Link <plink53@mac.com> wrote:
Jasen and Josh, does this help?
system_profiler -xml SPApplicationsDataType > ~/Desktop/SPlist
gives complete listing of all applications found on the Mac, including drivers and anything application related. Output is XML file stored wherever you want it.
Does this only apply to executable content installed through standard installation procedures? For example, if you have Google software (like Chrome) and its software updater regular downloads executables, runs them, then deletes them. Would these executables be captured by system_profiler? What about PHP, Python, R, Bourne shell code, etc.? Are these of interest? Todd
It's my understanding that system profiler tracks what is currently installed (software and hardware), that's it. If someone ran an application from a thumb drive then removed the thumb drive, system profiler won't list it after it's been removed. My thoughts on what SCAP content should and shouldn't do aren't necessarily in line with others but I was going to use it to validate the current configuration of Macs. I wasn't going to use it as a tool to monitor what someone has used their Mac for. When you look at USGCB configurations and how they are used, they are only validating a correct configuration, which can include whether patches and updates have been performed. Depending on how these standard configurations are defined, they might include the ability or lack of ability to run applications from external devices. In some government configurations, external ports might be disabled (hopefully system profiler will show this, I haven't checked. If not there are other ways to determine this) thereby potentially disabling the ability to run external applications. As I said, I don't believe the plan for SCAP content is to monitor these types of things. On Jul 15, 2013, at 6:25 PM, Todd Heberlein <todd_heberlein@mac.com> wrote:
On Jul 15, 2013, at 10:50 AM, Peter Link <plink53@mac.com> wrote:
Jasen and Josh, does this help?
system_profiler -xml SPApplicationsDataType > ~/Desktop/SPlist
gives complete listing of all applications found on the Mac, including drivers and anything application related. Output is XML file stored wherever you want it.
Does this only apply to executable content installed through standard installation procedures?
For example, if you have Google software (like Chrome) and its software updater regular downloads executables, runs them, then deletes them. Would these executables be captured by system_profiler?
What about PHP, Python, R, Bourne shell code, etc.? Are these of interest?
Todd
Peter Link LLNL retired plink53@mac.com
participants (4)
-
Jacobsen, Jasen W.
-
Josh Wisenbaker
-
Peter Link
-
Todd Heberlein