Cleaner Security Scripting

terminalIn previous articles, we have discussed making changes to the /etc/authorization file, also known as the authorization policy database or authorization database, using text editors.  Apple has a tool in Mac OS X that is specifically designed for that purpose.  /usr/bin/security, in addition to a multitude of other uses, security has a command called authorizationdb that allows for edits to the authorization database.

The authorizationdb command has three options, read, write and delete.  These function in much the same way as the defaults command is used to edit preference files.  Let’s use the previous article on setting DVD region codes as an example.  In that article, we discussed how to enable any user to set the initial DVD region code, but still require an administrative user to change the code once set.

To read the current authorization rule, we’ll use this command…

/usr/bin/security authorizationdb read system.device.dvd.setregion.initial

…which gives us the following output…

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>class</key>
     <string>user</string>
     <key>comment</key>
     <string>Used by the DVD player to set the region code the first time. Note that changing the region code after it has been set requires a different right (system.device.dvd.setregion.change).</string>
     <key>default-button</key>
     <dict>
          <key>en</key>
          <string>Set</string>
     </dict>
     <key>default-prompt</key>
     <dict>
          <key>en</key>
          <string>__APPNAME__ is trying to set the DVD region code for the first time.</string>
     </dict>
     <key>group</key>
     <string>admin</string>
     <key>shared</key>
     <true/>
</dict>
</plist>

Notes: Non-English strings in the default-button and default-prompt dictionaries have been removed for brevity.

The boldface “class” key and its value (emphasis mine) are the operative values that we are working with.  Using the write option for the authorizationdb command, we can make the same change described in the previous article, allowing any user to set the initial DVD region code, with a one-line script.

/usr/bin/security authorizationdb write system.device.dvd.setregion.initial allow

After running this command, if we read the contents of the system.device.dvd.setregion.initial key again using /usr/bin/security authorizationdb read system.device.dvd.setregion.initial, we now receive the following output…

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>rule</key>
     <string>allow</string>
</dict>
</plist>

Not only does /usr/bin/security simplify editing the authorization database, it also results in a cleaner entry.

I hope this is useful.

Setting A Default Paper Size

printerThis post is in response to a reader request.

In Mac OS X, the default paper size is a setting that determines the size of paper that applications will try to print to unless the user chooses otherwise. For most systems and applications this defaults to US Letter.  In order to provide a positive user experience, especially for end users outside of the United States, it may be desirable to set a different default paper size.

The file that contains this preference is:
~/Library/Preferences/com.apple.print.PrintingPrefs.plist

This makes the preference domain: com.apple.print.PrintingPrefs

The Key that governs the preference is called : DefaultPaperID

DefaultPaperID contains a string value that corresponds to a paper size. See the chart below:

Paper Size String
US Legal na-legal
US Letter na-letter
A4 iso-a4
A5 iso-a5
JIS B5 jis-b5
B5 iso-b5
Envelope #10 na-number-10-envelope
Envelope DL iso-designated-long-envelope
Tabloid tabloid
A3 iso-a3
Tabloid Oversize arch-b
ROC 16K roc16k
Envelope Choukei 3 cho-3-envelope
Super B/A3 arch-b-extra

To set this preference with a script use the command below, replacing with the correct string for the intended paper size.

For a single user, run as the user:
defaults write ~/Library/Preferences/com.apple.print.PrintingPrefs DefaultPaperID

For all users, run as root:
defaults write /Library/Preferences/com.apple.print.PrintingPrefs DefaultPaperID

This process has been tested on Mac OS X v10.6 (Snow Leopard), v10.7 (Lion) and v10.8 (Mountain Lion).

I hope you find this useful.

Consumerized IT or Bring Your Own

openLock

On any given day, I’m likely to have some form of conversation that includes a discussion of why no one should have administrative privileges, or why everyone should have them and IT shouldn’t care.  To paraphrase Mr. Kenobi, both arguments are correct, from a certain point of view.

The core of the issue comes down to determining what is most important to an organization.  Some organizations need extreme control and security.  In these organizations, having computers and devices locked down and only capable of performing approved tasks is required, often by law.  Many other organizations may not be bound by these laws or have as great a need for security and may instead place greater value on creative freedom and the flexibility to be productive according to an individual’s own work habits and quirks.  Since the locked-down model has been the IT standard for decades, we’ll leave that topic alone for now and instead discuss some of the ideas behind a consumerized model.

What Is Consumerization

The consumerization of IT is a topic that is in relative infancy, but rapidly growing, sort of like “cloud computing” was just a short few years ago.  Being a young and evolving concept, it’s not uncommon to to find varying definitions, and what follows is my own working definition as of December 2011.

“The Consumerization of IT” describes a trend where organizations expect employees to own a computer, be able to use said computer, and be able to obtain service and support for that computer.

Similar to the fact that most employers expect their employees to own and maintain phones and the means to get to work, a company following a consumerized IT model expects employees to own and maintain a computer.  These organizations may give employees a stipend to purchase the computer or may even provide a computer, but offer little to no support for the device or common commercial software.  This approach is often referred to as a bring-your-own or “BYO” model.

The primary goals of IT in a BYO scenario are to provide access to proprietary data and software tools that the user community needs to accomplish the organization’s goals rather than duplicating the support efforts of Apple, Microsoft, et al.  Schools worry about the educational process and a bread company worries about making and selling bread.  Both leave the business of Mac OS X support to Apple, Word support to Microsoft and Photoshop support to Adobe.

Why It Works

At the dawn of IT, we had to cope with baby boomers who grew up with slide rules and musty encyclopedias.  These people needed legions of helpers to translate the digital voodoo that would allow them to do their jobs.  Baby boomers are now retiring in droves.  Their children and grandchildren don’t need the same kind of handholding.

Also consider the fact that the young people who have entered the workforce in the past several years, and will be entering it going forward, have grown up with computers almost since birth.  These people came through school using the Internet, word processors and cellular phones.  Children born on the day the Internet was opened to commercial activity have bachelor’s degrees now.  These young adults may have been using an iPhone for as long as or even longer than their employers.  Aside from having a level of competence with technology, and perhaps because of it, these employees are more likely to chafe against a tightly locked system.

Some Management

Whether it’s software distribution, managing compliance with legal guidelines, providing critical software patches, or configuring an email account, even organizations that have consumerized IT will benefit from some degree of client management.

Since the end user will be in ultimate control of the computer, it is important to have clear communication between IT and the user regarding the management tools used and what is expected of each party.  A balance must be struck between the privacy needs of the employee and the security needs of the employer, and the stipulations of that balance should be well understood by both parties.

How It Works

Since the end user has administrative privileges, common IT terms like “push” and “lock” don’t apply.  To have effective management, we need to link compliance with desired and/or required items.  Examples might include automatically locking out a user’s directory service account if their computer doesn’t comply with security requirements or removing network access and/or email configurations if the device fails to meet other agreed-upon management requirements.  In this way, we are able to give the end user the tools they need, but only when they agree to and comply with the organization’s policies and requirements.

Software installations and even many management tasks may be delivered by a client-driven mechanism, such as The Casper Suite’s Self Service tool or similar mechanisms; although there will likely be some settings such as those discussed above that will be enforced as a mandatory requirement of participating in the BYO program.

It is important to design the systems and processes involved to be as simple, user friendly and foolproof as possible.  While today’s end users tend to be more savvy than their predecessors, not everyone is a technology nerd, and shouldn’t be expected to be one.  Apple users in particular expect things to “just work.”  Maintaining that same high level of usability should be a requirement of any BYO project.  If something can be done in two clicks, don’t make the user do it in three.  Make sure interfaces are labeled well and consistently.  Finally, always use the system yourself.  You can’t relate to your users’ frustrations very well if you never use the systems they use.  If you find yourself not wanting to use a system, that’s a great indication that the system needs work.

I hope this overview proves useful.  We may explore these concepts further in future articles if there is significant response.

Scripting: Using cut to Capture Information

terminalIn the previous article we discussed using grep and awk to harvest information.  The final example in that article may have left us wanting.  In this article, we’ll discuss some additional options that the cut command can give us.

As we discussed, the following command:

diskutil info / | grep "Volume Name:" | awk '{print $3}'

would output the name of our boot volume, assuming there were no spaces in it.  However, if our target Mac had a factory standard boot volume called “Macintosh HD”, we’d need to change our command to:

diskutil info / | grep "Volume Name:" | awk '{print $3,$4}'

If there were more than one space in our volume names, well, it all becomes a bit much to manage. Unfortunately, awk doesn’t provide a method to display word X and all following words, so we will look to another command called cut.

According to its man page, cut is designed to “cut out selected portions of each line of a file”.  Cut can work with “words”, like awk, or it can work with characters.  We’ll look at working with words first.  Unless specified otherwise, cut assumes that words are delimited (separated) by tab characters.  If the delimiter is something other than a tab, the delimiter must be defined using the “-d” option.  After defining the delimiter, we must tell cut which words we would like to output.  We do this using the -f option, followed by a number indicating the word’s position.  Unlike awk, we do not need a “$” or other character to indicate our word selection, just the number.  Also unlike awk, we can specify a range, including “X-” which tells cut to return the word at position X and everything after it, which we will do below.

diskutil info / | grep "Volume Name:" | cut -d ' ' -f 19-

The “-d” option has indicated that our delimiter is a space.  The “-f” option has asked for words 19 through the end of the line.  This may seem a bit confusing because if you look at the output of the first two commands, it would seem that we would be interested in word number 3 and onward.  It would appear that diskutil’s output contains both spaces and tabs, and a bit of trial and error helped to arrive at the number 19.  This command will return our boot volume’s name regardless of the number of spaces in the name.

The other option when working with cut is to simply count characters.  This precludes a need to define a delimiter.  By counting characters, we can find the same information with the following command:

diskutil info / | grep “Volume Name:” | cut -c 30-

This line will return character number 30 and all characters that follow it.  Like the example using the -d and -f options, this will return our boot volume’s name regardless of the number of spaces in the name.

We see that cut can provide us with some capabilities that awk doesn’t.  Hopefully this examination will help you to capture data in your own scripts.

The commands in this article have been tested on Mac OS X versions 10.5.8 and 10.6.7 (build 10J869).  Thanks go to Lisa at lisacherie.com for assistance in testing the commands used in this article.

Scripting: Getting Volume Details Using grep and awk

terminalAs sysadmins, we often need to write scripts that will interact with hard disks or other volumes on a client computer.  These scripts usually need some information about the volume(s) being worked with, such as a device identifer, UUID, etc..

I often see my fellow sysadmins making assumptions such as a Mac’s boot volume will be known by the device identifier “disk0s2”.  While this is often the case, it is by no means guaranteed.  For my money, often being correct isn’t acceptable, especially when always being correct can be achieved with a relatively short command. In this vein, I will outline some commands to harvest various volume information below.

Device Identifier

Some disk management commands require a device identifier.  The device identifier is in the format diskXsY.  diskX refers to a physical device.  sY refers to a volume or “slice” of diskX.

diskutil info / | grep "Device Identifier" | awk '{print $3}'

Volume UUID

The Volume UUID, or Universally Unique IDentifier, is a unique ID code generated for every volume.  The UUID is required for some disk operations.  Volume UUIDs are persistent regardless of your currently booted system.

diskutil info / | grep "Volume UUID" | awk '{print $3}'

Volume Name

Sometimes we’ll need to know the name, also referred to as the “label”, of a volume.  This is the name we see displayed in Finder.

diskutil info / | grep "Volume Name:" | awk '{print $3}'

Breaking It Down

You may have noticed a pattern in the commands above.    All of the sample commands begin with “diskutil info.”  Simply executing “diskutil info” followed by a volume, will output a list of information about that volume.  In the example commands above, we use “/”, which refers to the current boot volume.  By replacing “/” with “/Volumes/<otherVolumeName>” we can retrieve information from other volumes mounted on the Mac.  The pipe or “|” character passes the output from this command to the next one.

The next command is “grep”, followed by a quoted term.  Grep is a very powerful UNIX tool, but here, we’re using one of its most basic functions.  Grep will look within the text that it receives as input, in this case the output of “diskutil info /”, for the search term we’ve provided.  If the term is found, grep returns the entire line (s) on which our search term appears.  The grep output is then piped to the next command.

awk is another powerful tool;  books with page counts in the hundreds have been written about it.  Like grep, we are using one of awk’s more simple functions here.”awk ‘{print $X}'” takes the input it is given, the output of the grep statements in these examples, and returns the “word” at position X.  I’ve put “word” in quotes because awk doesn’t define word the same way as the English language does.  To awk, a word is a string.  Words are separated by spaces.  If we run our last example command (diskutil info / | grep “Volume Name:”) on a system booted to a volume called “BootDrive”, the output from the first two parts of the command  is ”   Volume Name:      BootDrive”.  In this case, “Volume” is word 1, “Name:” is word 2, and finally “BootDrive” is word 3.  This is why we ask awk to return word 3.

Note that if your volume name has a space in it, such as the factory default “Macintosh HD”, the command listed above would only return the first word of your volume name, for example, “Macintosh”.  To get awk to return multiple words, multiple words can be referenced inside the brackets, separated by commas.  For example “awk ‘{print $3,$4}'” would return the words at positions 3 and 4, with a space between.  We could repeat this for as many words as you need.  such as “awk ‘{print $X,$Y,$Z…..<and so on>}'”.  It is not necessary to choose consecutive words either.  “awk ‘{print $1,$5}'” would work just as well.  Referencing empty word positions will not generate any output, meaning that if we executed “diskutil info / | grep “Device / Media Name” | awk ‘{print $3,4}'” on a system with a boot volume called “BootDrive”, our output would be simply “BootDrive”.

Well, I hope some of you have found this exploration useful.  Future articles will build on what we’ve discussed here.

Casper Suite: Firmware Updates Extension Attribute

casperSuiteAs promised, here is the follow up to my previous post.

People who have followed this blog will know that I like zero touch. Unfortunately, firmware updates usually require physically touching a computer. In the absence of a scriptable robot that can go around to users’ desks pressing buttons, this process is hard to automate. Thankfully, firmware updates are relatively infrequent compared to other Apple Software Updates.

Using an Extension Attribute in the Casper Suite, I have been able to achieve the following goals…

  • Automate Apple Software Updates without continually running Software Update on computers that only have firmware updates available.
  • Generate a list of computers that require firmware updates.  This list is given to technicians as a work list of computers to visit and run the firmware updates on.

Here’s the script to use in the Extension Attribute (I call it “Available FWUs”)…

#!/bin/bash
# Populate "Firmware Updates Available" extension attribute
# Get firmware update count
fwupdcount=`softwareupdate -l | grep -c -e Firmware -e firmware -e EFI -e SMC`
echo "<result>$fwupdcount</result>"

The fourth line is looking for available software updates with names that contain the terms “Firmware”, “firmware”, “EFI”, and “SMC”.  This covers all of the firmware updates I can find on apple.com/support.  If additional terms become needed in the future, one can add ” -e <desiredTerm>” to the command between “SMC” and the final backtick.

The result will be an integer.  An Advanced Search for computers with Available FWUs more than 0 will give you the firmware update work list.  I use a Smart Computer Group containing computers with Available SWUs more than 0 and Available FWUs less than 1 as the scope for an automated Software Update policy.

I hope this is helpful!

Note: Recent Apple firmware updates haven’t been requiring manual interaction.  This process may not be needed if your environment consists solely of new hardware.

Reprint: Extending the Casper Suite with Dummy Packages

mt-cover-0909Questions about this article have come up in conversations with other Mac sysadmins.  As the reprint rights have since reverted back to me, I’m glad to share the content.

This content is copyright © 2009 by Miles A. Leacy IV.  Permission is granted to redistribute the article in it’s unaltered form.

Download the article at the link below (opens in a new window):

https://drive.google.com/open?id=1Qax-mKcTWgBnu9IANZGORyaiLDG65VV1

A few notes:

  • The Dummy Package/Dummy Receipt workflow is no longer necessary as of Casper Suite version 7.  Extension Attributes provide the same functionality in a much more usable (not to mention supported) fashion.
  • The script contained in the article can be altered to be used in an Extension Attribute. This will be covered in a follow up post on this site.
  • You may want to add terms other than “Firmware” to the script, such as “SMC”, “EFI”, etc., to cover all known firmware updates.

I hope some of you will find this article useful.

NSA Security Recommendations Part 1

securityThe United States National Security Agency has published a pamphlet titled Hardening Tips for the Default Installation of Mac OS X 10.5 “Leopard” (title links to document).  I consider many of these tips to be no-brainers, some to be best practices, and the rest have variable value depending on your organization’s requirements.  This article is the first of a series in which I’ll examine each of these tips, how to automate their implementation, and discuss any caveats for each.

Note: The NSA document, and therefore this series of articles, refer specifically to Mac OS X version 10.5 (Leopard). The ideas and techniques should transfer to 10.6 (Snow Leopard), but be sure to test carefully before putting into production. I will discuss any changes required to implement each recommendation in 10.6.

 

Don’t Surf or Read Mail using Admin Account

This falls into the “no-brainer” category.  I firmly believe that in an organization where the end user does not own his or her computer, there is no reason for that user to have administrative rights on the system.  For every so-called valid reason to grant administrative permission that I have encountered, there is a workaround that can give the user the ability to do their job without granting admin rights.  If you find yourself fighting against an organizational culture that wants admin rights for end users, you can counter with this statement:

 

“If end users have administrative rights, no IT group can make any guarantees or reliably satisfy any SLA regarding the performance, security or continued operability of the systems in question.”

 

Put simply, if unqualified people can mess with the works, then all bets are off.

 

Not being a technical procedure, this concept holds true for Snow Leopard, all other versions of Mac OS X and for any other OS as well.
If you believe you have a valid reason to grant administrative privileges to end users or your organization is forcing you to grant those privileges for a particular reason or reasons, please leave a comment. I’ll do my best to describe a solution to the given problem without granting administrative rights.

Script: Enable Remote Management (ARD)

terminalHere’s another script for zero-touch deployment. If you want to enable Remote Management for Apple Remote Desktop access, this script will get you there.

This script uses the kickstart command which is buried within the ARDAgent application. Entering the following command in Terminal will display the full listing of options and examples available with this tool.

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart help

I have most commonly enabled the Remote Management service, granted all privileges to a single local admin user used by IT staff, and restarted the agent and menu extra to allow the agent to read the new configuration. The script below will accomplish these items. Reviewing the kickstart help will give you the syntax to write your own script to accomplish different Remote Management configurations.

#!/bin/bash

##### HEADER BEGINS #####
# scr_sys_enableARDforAdminUser.bash
#
# Created 20081231 by Miles A. Leacy IV
# miles.leacy@themacadmin.com
# Modified 20090812 by Miles A. Leacy IV
# Copyright 2009 Miles A. Leacy IV
#
# This script may be copied and distributed freely as long as this header
# remains intact.
#
# This script is provided "as is". The author offers no warranty or
# guarantee of any kind.
# Use of this script is at your own risk. The author takes no responsibility
# for loss of use,
# loss of data, loss of job, loss of socks, the onset of armageddon, or any
# other negative effects.
#
# Test thoroughly in a lab environment before use on production systems.
# When you think it's ok, test again. When you're certain it's ok, test
# twice more.
#
# This script:
# - enables the Remote Management service (ARD)
# - grants access and all privileges to the user "admin"
# - restarts the ARD agent and the ARD menu extra
#
# This script must be run as root (done automatically when deployed with
# the Casper Suite).
#
# When using the script with a Casper Suite configuration for imaging,
# set it to run At Reboot.
#
##### HEADER ENDS #####




/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -users admin -privs -all -restart -agent -menu

Printing For Non-Admins In Leopard

printerThis is a topic I’ve seen covered in many places, however most of the articles I see on this topic only get part of the solution or solve it in a way that creates unnecessary security issues.  In light of this, I’ve decided to talk about what I consider to be the best practices on the subject and the reasons why.

Why Did Apple Limit The Printing System?

Unless you know why Apple imposed security restrictions on the printing system, it seems pretty silly and detrimental to users.  After I understood the reasons behind the change, it made a lot of sense.

When you add a printer in CUPS (Common UNIX Printing System, the printing software under the proverbial hood) and specify a PPD file for that printer, the PPD file can, and often does, run software as root.  This function of the printing system could be used to run malicious code.  To help mitigate this risk, administrator authentication is required if the logged in user is not an administrative user or if the “Require password to unlock each System Preferences pane” box has been checked in the Security System Preferences Pane.  None of this is an issue in the “typical” home computer installation since there is only one user and that user is an administrator.  For environments that require extra security, indicated by having standard (non-admin) user accounts and/or system preference restrictions, this vulnerability is closed.

Make A Spare Key; Don’t Remove the Door

Many of the blogs and forum posts I’ve read on this subject advocate the removal of CUPS security features.  If this sounds like a good idea, ask yourself this; if you wanted to give someone access to your home, would you take your front door off its hinges or give this person a key?  I think the answer is clear.

Understanding The Lock

Before we can make our “spare key”, we need to understand how the lock works.  to do that, we’ll look at the default CUPS configuration file, found at /private/etc/cups/cupsd.conf and how it defines CUPS Operation policies.  Every Mac OS X Leopard installation includes detailed documentation on this subject at http://localhost:631/help/policies.html (link opens in a new window)  For our purposes, we’ll look at the specific section of the cupsd.conf file that covers adding, deleting and setting default printers, but this URL is your best reference for CUPS operation and configuration.

# All administration operations require an administrator to authenticate...
     <Limit CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class
CUPS-Delete-Class CUPS-Set-Default>
          AuthType Default
          Require user @SYSTEM
          Order deny,allow
     </Limit>

The line that reads Require user @SYSTEM is what dictates that administrative authentication is required.

Making the Spare Key

Many people are recommending deleting or commenting out this block of text. This is the equivalent of taking the door off of the hinges that I mentioned. Instead, we can modify this block to grant permission to groups that we define, rather than removing the security feature. If we add user or group names to the line that reads Require user @SYSTEM, those users and members of those groups will be granted the add, delete and set default permissions. See the example below…

# All administration operations require an administrator to authenticate...
     <Limit CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class
CUPS-Delete-Class CUPS-Set-Default>
          AuthType Default
          Require user @SYSTEM @admin @lpadmin @mycustomgroup
mycustomuser
          Order deny,allow
     </Limit>

This modification allows the members of the admin, lpadmin and mycustomgroup groups and the user mycustomuser to add, delete and set default printers. Group names require the preceding “@” character, usernames do not.

Going Further

There are other default policies in the default cupsd.conf file that govern pausing & resuming queues, holding & deleting print jobs, etc. These policies can be modified in the same way. The CUPS help file (link at the top of this article) contains details on 38 different printing system operations that can be governed by the cupsd.conf file and detailed instructions on creating your own policies within the file. Using that information, you should be able to configure virtually any required or desired security settings.