Managing Mac OS X on hundreds of diverse computers throughout an enterprise organization creates many challenges for IT managers and staff. Many of these issues can be attributed to the differences between the Mac OS X and OS 9 security models, operating system architectures, and distribution and management tools. As an enterprise system administrator, it's important to evaluate the factors for distribution and deployment of software by tracking installations. In this article, I'll show you a few options to help you configure the best system for your situation.
With the rise of malicious code, viruses, and worms targeting known vulnerabilities, security -- both in regards to the network and platforms on it -- is a more significant concern for all enterprise deployments. The resultant downtime, its associated expense, and increased concern arising from governance and regulatory compliance (e.g., HIPAA, Sarbanes-Oxley, and FERPA) requires the enterprise to focus on computer security.
In addition, with Mac OS X, inroads have been made into previously unavailable environments, such as the federal system and military, where the security of a client operating system is of critical importance. While Mac OS 9 was a "closed" operating system, with little or no access to internal code and no command line, Mac OS X is an open source operating system based on Unix. Access to a wide variety of open source software has increased the ability to compromise a system that was not available in Mac OS 9. For installers, it is important to:
Tracking installations has many benefits for the system administrator. Mac OS X has seen an increase of distribution tools. When combined with installation tracking, an administrator can reduce time spent developing new systems for deployment as well as minimize the amount of time required to deploy the new system. Efficiency is highly important, particularly in a small information technology department.
In the enterprise, a primary goal is often to provide a uniform experience for all end users. By creating a uniform experience, unexpected problems break in a consistent manner. If the software has been tracked, a problem can be fixed simply and efficiently throughout the enterprise. An additional benefit is that tracked software is much easier to troubleshoot, as the scope of possible problems is a known quantity.
Increasingly, in enterprise environments, resources are limited. With installation tracking, the management cost of security, efficiency, and consistency is reduced.
With the above considerations in mind, the tracking of installers becomes even more critical for the enterprise system administrator. Smaller departments and companies can benefit from tracking installers, as they will reduce the amount of resources spent in this endeavor.
One reason installers cannot be trusted is improper use of file permissions and modes. Normally, an application runs with permissions of the logged-in user. Only files and directories that have correct user permissions are affected. Installers may create files with the following permissions:
-rwswr-xr-x-rwxr-sr-x-rwxrwxrwxWhy are these file permissions undesirable? If the application has a programming error, buffer overflow, or other security issue, it may be exploited by a malicious user who can use these elevated permissions to affect secure areas of the system. Additionally, files and folders may be unintentionally overwritten or modified.
Another reason that installers cannot be trusted is the unnecessary use of administrative rights. If an application does not install in protected system areas, the use of administrative or root user rights are unnecessary. This requirement can also prevent installation of software by a non-administrator to protected areas of the file system. In many environments, non-administrative users are allowed to install applications in their user file spaces. As a second consequence, this unnecessary requirement can lead to careless use of administrative credentials. This issue gives opportunities for hackers to create installers used to compromise systems.
As an example, the recent Office 2004 malware released could have been created using administrative privileges. With this additional ability, an end user with administrative privileges could cause significant damage to a Mac OS X installation.
Lastly, files from installers are placed in non-standard locations. Installers that do not follow recommended guidelines on installation create an increased burden for enterprise information technology staff when tracking and troubleshooting installations. Apple documentation (the Mac OS X HI Guidelines) even specifies, "During installation you should install your application in a location accessible to all users. Most of the files you generate while your application is running, however, should go in the user domain because they pertain to the specific user currently using that application."
Since installers cannot be trusted, what are the first steps used to track any software installation? Let's examine some simple methods used to track software installations. These methods track only Apple Package installers. Tracking installations created by other installers is more complex, and does not use the following methods.
The simplest way to begin tracking an installation using a package archive is to use the Apple Installer program. With the Installer, an administrator can determine what is being installed and where. As an example, iTunes 4.5 uses a package archive. Let's begin by examining some screenshots of what the Installer provides.
In this window, the file listing is shown. It's only available after an installation destination has been chosen. Meta-packages are supported, as well as printing the entire listing of files being installed. It can be accessed from the File -> Show Files menu.
Shown in this dialog is a log listing all steps of the installation. Any scripts run as part of the installation, such as permission corrections or temporary file creation, will appear in this log. Three view options are available: Show Everything, Show Errors and Progress, and Show Errors Only. You can also access this feature from the File menu. This technique starts the process of tracking an installation. So what's missing?
You may notice that the file listing, while complete, does not provide any permission information, or the checksum for installation verification. The next level of tracking an installation uses the shareware product, Pacifist™.
|
Pacifist uses a package archive's binary file, package.bom located inside of the archive. This file lists the file or directory path, user (UID), group (GID), permissions, modes, and the checksum of files. It is commonly referred to as the "bill of materials" file. Possible modifications made by installer scripts are not included as part of a .bom file. Tracking an installation in this way allows an enterprise administrator to check for security concerns of, or problems with, the package installer.
Continuing with the previous example, iTunes 4.5, Pacifist presents a more complete set of information.
In this dialog, a more complete set of information about the files being installed is presented. Important pieces of information are shown, including:
Pacifist also allows extraction of individual pieces of the package to a temporary location. However, if the package is extracted in this way, it will not run any scripts that are part of the installation as detected by Installer.
Pacifist can also be used as a replacement for the normal Installer, which can be helpful if you're experiencing problems with the software installation package. Additional advantages include the ability to verify existing installations and compare files of an installed package with the files listed in the package installer. It will also detect missing files and files that have different permissions or checksums, and can update prebinding information, either for the entire hard disk, or for an individual folder.
The last simple way that a package file can be tracked is by using the
command-line utility lsbom. This command-line binary
interprets the content of the bill of materials file (pkg.bom), and produces output formatted
containing the POSIX path of the entry, its mode (octal), and its
UID/GID. The tool also does not list possible modifications made by
installer scripts.
lsbom -p MUGTsfc iTunes4.bom
drwxrwxr-t root admin .
drwxrwxr-x root admin ./Applications
drwxrwxr-x root admin ./Applications/iTunes.app
drwxrwxr-x root admin ./Applications/iTunes.app/Contents
-rw-rw-r-- root admin Fri Apr 16 15:30:25 2004 13489 ./Applications/iTunes.app/Contents/Info.plist 412288683
drwxrwxr-x root admin ./Applications/iTunes.app/Contents/MacOS
-rwxrwxr-x root admin Wed Apr 21 16:10:52 2004 4696188 ./Applications/iTunes.app/Contents/MacOS/iTunes 1822652320
-rw-rw-r-- root admin Mon Dec 8 19:25:15 2003 8 ./Applications/iTunes.app/Contents/PkgInfo 187102783
drwxrwxr-x root admin ./Applications/iTunes.app/Contents/Resources
Comparing the information with the graphic dialog from Pacifist, an identical set of information is presented. For more
information about the command-line switches, read the manual page, man lsbom. An advantage to using the command-line tool is the ability to read scripts run as part of the installation process. For example, in the iTunes 4.5 installer,
a script, iTune4.pre_install is included.
#!/bin/sh
if [ -e "/Applications/iTunes.app" ] ; then
rm -rf "/Applications/iTunes.app" 2> /dev/null
fi
/usr/bin/sudo -u $USER "$PACKAGE_PATH/Contents/Resources/InstallHelper" "/Applications/iTunes.app/Contents/Resources/iTunesHelper.app" 2> /dev/null
"$PACKAGE_PATH/Contents/Resources/InstallHelper" 2> /dev/null
exit 0
The use of shell scripts as part of the installation can be used to correct or modify installations before or after they have completed.
Each package that is installed creates a receipt file in /Library/Receipts. As an example, the following listing is from the iLife.pkg.
drwxrwxr-t root admin .
drwxrwxr-x root admin ./private
drwxrwxr-x root admin ./private/var
drwxrwxrwt root wheel ./private/var/tmp
-rw-rw-rw- root admin 442 ./private/var/tmp/BlankFile 3626504269
Note the permission mode setting for /private/var/tmp: drwxrwxrwt. By tracking the installation as shown above, you can check file permissions for inconsistency. If an installer incorrectly modified /tmp, removing the sticky bit, a potential security hole is created, as listed in AusCert advisory AA-95.07. You could then proactively correct any potential security hole discovered in a Receipt file.
One very popular type of installation on Mac OS X is the "drag-and-drop" method of installation. Tracking this type of installation
is very simple with the command-line tool ls. Using ls with the correct command-line switches, a complete listing of
installed files can be created. Using the following command:
ls -latRproduces the following listing for an application.
Much of the information provided is similar to a package installer. However, note that no checksum information is provided as a drag-and-drop installer is simply copying the file from a disk image, and does not have any method for file integrity verification.
From a developer's standpoint, the advantage of using Packages is tremendous. Why?
Hopefully, this basic guide has provided you with additional insight into the basic methods of tracking installations in business and educational environments.
Philip Rinehart is a member of the steering committee leading the Mac OS X Lab Deployment Project (www.macosxlabs.org) and manages Macs as a support specialist at Yale University.
Return to the Mac DevCenter
Copyright © 2009 O'Reilly Media, Inc.