Tuesday, November 11, 2014

Playing with pwpolicy

I had a colleague ask me recently about the changes to Mavericks pwpolicy. Not having touched the tool in a few years, I was curious about the changes. Well, as the saying goes, I'm now one dead little kitty.

pwpolicy gets and sets the password policies for users on OS X. I believe binding to a directory service is required and these settings don't apply to local accounts, however I could be wrong about that, as Apple has now published an article on how Global policies can lock out admin accounts. Yay?

pwpolicy now has deprecated the commands we would have used in the past. In their place are multiple new Account Policy Keywords. All in all, it seems like a good move to use policy keywords as it will be much more customizable in the future. However, at the moment the pwpolciy man page makes my head hurt. I'm failing to grasp the whole picture here, and it's keeping me from grasping the new way of doing policies. I hope to learn more, but in the mean time I've played with the example plist in the man page. With a few simple modifications, I've added checking for numeric and non-numeric characters, as well as mixed case strings.

It appears that these policies use regex to check the password, where the new password is the variable "policyAttributePassword" and when the RegEx "matches" that it continues on.

Again, all conjecture as I've not been able to test or confirm. I am curious as to where the supplemental documentation is....Apple? Anyone else have some idea as to what's going on here? Perhaps willing to present it at a July conference in PA?


Test Plist...

<dict>
<key>policyCategoryPasswordAuthentication</key>
<array>
<dict>
<key>policyContent</key>
<string>policyAttributeMaximumFailedAuthentications &lt; policyAttributeFailedAuthentications</string>
<key>policyIdentifier</key>
<string>failed auths</string>
</dict>
</array>
<key>policyCategoryPasswordChange</key>
<array>
<dict>
<key>policyContent</key>
<string>policyAttributeCurrentTime &gt; policyAttributeLastPasswordChangeTime + policyAttributeExpiresEveryNDays * DAYS_TO_SECONDS</string>
<key>policyIdentifier</key>
<string>Change every 182 days</string>
<key>policyParameters</key>
<dict>
<key>policyAttributeExpiresEveryNDays</key>
<integer>182</integer>
</dict>
</dict>
</array>
<key>policyCategoryPasswordContent</key>
<array>
<dict>
<key>policyContent</key>
<string>policyAttributePassword matches '.{8,}+'</string>
<key>policyIdentifier</key>
<string>com.apple.policy.legacy.minChars</string>
<key>policyParameters</key>
<dict>
<key>minimumLength</key>
<integer>8</integer>
</dict>
</dict>
<dict>
<key>policyContent</key>
<string>policyAttributePassword matches '\D'</string>
<key>policyIdentifier</key>
<string>com.apple.policy.legacy.requiresAlpha</string>
</dict>
<dict>
<key>policyContent</key>
<string>policyAttributePassword matches '\d'</string>
<key>policyIdentifier</key>
<string>com.apple.policy.legacy.requiresNumeric</string>
</dict>
<dict>
<key>policyContent</key>
<string>policyAttributePassword matches '.*[A-Z][a-z]+'</string>
<key>policyIdentifier</key>
<string>com.apple.policy.legacy.requiresMixedCase</string>
</dict>
</array>
</dict>

Wednesday, August 6, 2014

Code Signing Signature v2

Twitter and IRC have been ablaze this morning with chatter about OS X signed apps in Yosemite DP5. First to reach my eye was the twitter post from Graham Pugh
https://twitter.com/grahamrpugh/status/497023675695398912
Apple explains...

"Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.

For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature."

Not being a developer by trade, I wasn't concerned with the implications of version 2 signatures for signing apps as much as I was curious as to how many of the current apps we deploy could fail. I'm unsure, and won't bother to confirm until Yosemite GM is released, wether or not Apple will block our unsigned or version 1 signed applications from launching. My guess is no, but we will see.

Until we have a Yosemite GM to test against, I wanted to get a cursory look at the signature version of all our applications. To do this, I adapted the shell one-liner of dirkg from the IRC ##osx-server channel. The one-liner provides a number of applications that are signed with version 1, version 2, or none:

find /Applications /Applications/Utilities/ -maxdepth 1 -name "*.app" | while read a ; do codesign -vd "${a}" 2>&1 | awk '/version/ {print $3}' ; done | sort | uniq -c

While this command helped me determine we have over a hundred applications signed with version 1 signatures, it didn't tell me which applications.

Introducing "CertSignatureVersion.sh", my adaptation that prints out both the application path and the signature version. 

Apple's documentation also references the spctl command for testing applications signatures. According to Apple's documentation spctl will "check if Gatekeeper will accept your app's signature".  Test your applications on the latest Yosemite developer preview with the following command:

spctl -a -t exec -vv Foo.app


Tuesday, October 22, 2013

Mavericks Install USB

For the past few iterations of the OS X installer, we've had to take a few steps to create a bootable usb install drive. While this process has not been difficult, it has had generated a few blog posts on the subject. Erica Sadun provides a write up of a common method used to create the external USB install here. Greg Neagle has developed a way to turn the installer into a package for deploying with other tools, which  can be found here.

In the early days of development on Mavericks, Apple changed the install app causing the previous methods to fail. Another set of blog posts emerged with details on the process, including how to copy a folder of packages after restoring the InstallESD.dmg. Dan Desilva provided this Tips and Tricks article to help others navigate the deluge of folders and create a working Mavericks install usb drive for developers.

Now, with the public release of OS X Mavericks, Apple has provided a tool to create an usb install drive. Located within the "Install OS X Mavericks.app" we can find the tool "createinstallmedia". Here's the full path (Watch for line breaks on the copy/paste):
/Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia 

Running the tool in the terminal provides us this usage statement...

Usage: createinstallmedia --volume --applicationpath [--force]

Arguments--volume, A path to a volume that can be unmounted and erased to create the install media.
--applicationpath, A path to copy of the OS installer application to create the bootable media from.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.

Example: createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install OS X Mavericks.app

This tool must be run as root.

The binary takes three arguments when it is run, including the volume to place the installer on, the path to the installer, and the option to create it without any confirmation.

I ran the tool and, after a few minutes, was greeted by an Install OS X Mavericks drive on my desktop. Needles to say, I was giddy! It was very painless and quick, a nice change to the process I was familiar with. I can confirm that the usb installer worked on my test mini, and have no doubts about it's abilities to install the latest fresh juice squeezed from Cupertino.

Now it's your turn. Find an old USB drive and slap it into the closest Mac with the latest 10.9 install app. Fire up your terminal and make your own, you don't really need 32 gigs of fish stick recipes, do you?!

sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/FishStickRecipes --applicationpath /Applications/Install OS X Mavericks.app

I love not having to open Disk Utility and copy folders around. This tool makes this admin very happy!

Wednesday, March 13, 2013

OS X Mountain Lion Screensaver at the Loginwindow


With the release of OS X Mountain Lion (10.8), Apple discontinued supporting custom slidesavers over the loginwindow. Prevously, on OS X Lion, we used an existing slidesaver and modified it to fit our needs as document here: http://www.mactech.com/articles/mactech/Vol.26/26.02/2602MacEnterprise-CustomSlideShowScreenSavers/index.html

Moving ahead with Mountain Lion requires that we take another look at how we configure the loginwindow screensaver. If you're not interested in doing things using the Apple way, you may like the prepackaged solution provided by University of Utah called "10.5 Logout Saver Screen Preserver": http://www.macos.utah.edu/documentation/system_deployment/xhooks.html

If you're still interested a way to use a folder of images as a screensaver for OS X Mountain Lion and you don't want to install extra XHooks stuff, keep reading...

The basic crux of the issue is that there is no GUI for configuring the loginwindow screensaver to use a folder of images. In fact, there isn't any documentation from Apple, that I can find, to configure the loginwindow screensaver. To configure the screensaver we'll have to use the System Preferences GUI and the terminal, so lets get started!

The first step involves configuring the screensaver inside a user account. This is the simplest of the steps and as such I won't go into much detail. You open the Screen Saver preference pane and select a folder of images to use. That's it, just remember to set the users screensaver back to whatever you would like it to be when you're done.

Now that you've selected the folder, two new files have been created for your user. These two files, named com.apple.ScreenSaverPhotoChooser.GUID.plist & com.apple.ScreenSaver.iLifeSlideShows.GUID.plist (Where GUID is your machines ByHost identifier), hold settings that configure the "iLifeSlideshows.saver". The "iLifeSlideshows.saver" ends up being the replacement to your custom slidesaver from the previous OS. Instead of the system using your slidesaver, it uses the iLifeSlideshows.saver and looks for the aforementioned preference files to determine which folder of images should be shown. The System Preferences writes these preference files to /Users/username/Library/Preferences/ByHost/. Find them and copy them to /Library/Preferences now, I'll wait here.

So, now that we've got those two files moved to /Library/Preferences, you should rename them to remove the ByHost GUID. You will end up with file names /Library/Preferences/com.apple.ScreenSaver.iLifeSlideShows.plist & /Library/Preferences/com.apple.ScreenSaverPhotoChooser.plist. Lets take a look at these and modify them to our needs. 

To view the files we can use the defaults command. In the Terminal.app type this:
defaults read /Library/Preferences/com.apple.ScreenSaverPhotoChooser.plist
defaults read /Library/Preferences/com.apple.ScreenSaver.iLifeSlideShows.plist 
 Our first file "com.apple.ScreenSaverPhotoChooser.plist" shows this:

{
    CustomFolderDict =     {
        identifier = "/Library/Preferences/Slides/edu.psu.slides";
        name = "edu.psu.slides";
    };
    LastViewedPhotoPath = "";
    SelectedFolderPath = "/Library/Preferences/Slides/edu.psu.slides";
    SelectedSource = 4;
    ShufflesPhotos = 1;
}
We can see that the preference file has the directory of images that we set in System Preferences. We can also see a few other keys are set. If you want to change the path to the slides, you could do so by editing the SelectedFolderPath and identifier under the CustomFolderDict. Hopefully we've got those set correctly and can move on. In my testing, I found that the SelectedSource key and CustomFolderDict were unnecessary. LastViewedPhotoPath is auto generated, so really the only keys needed are SelectedFolderPath and ShufflesPhotos. Your milage may vary.


The second file "com.apple.ScreenSaver.iLifeSlideShows.plist" shows this:
{
    spansScreensKey = 0;
    styleKey = Classic;
}
The spansScreensKey, I assume, tells the screensaver to show on multiple screens. I've not yet tested this. The styleKey seems to be the way in which the photos appear. One of the alternate styleKeys is "Flipup". I'd like to collect more here, eventually.

Now that we've modified the two files from our user account, we need to tell the system to use the iLifeSlideshows.saver at the loginwindow, as well as how long to wait before doing so.
Check to see if you've already got a "com.apple.screensaver.plist" with this command:
defaults read /Library/Preferences/com.apple.screensaver.plist
Chances are you've not got one. That's fine, we can make one very easily. To configure the system to use the "iLifeSlideshows.saver", which will show our folder of images, we can use this defaults command:
defaults write /Library/Preferences/com.apple.screensaver.plist loginWindowModulePath "/System/Library/Frameworks/ScreenSaver.framework/Resources/iLifeSlideshows.saver"
Careful of line breaks when copying and pasting, check before you hit enter!

Once we've got the correct screensaver chosen, we need to tell the system how long to wait before activating the screensaver over an idle logininwindow. Use this command with the number of seconds to wait:
defaults write /Library/Preferences/com.apple.screensaver.plist loginWindowIdleTime 60
Hopefully it makes sense to you that this would set the loginwindow to show the screensaver after 1 minute. 

Now you can restart your machine and your folder of pictures should appear over the loginwindow after a minute of being idle! Try packaging the files and picture folder for making the deployment easier in the future.

TL;DR

Enable screensaver with these three preference files and a folder of images at /Library/Preferences/imagefolder/:

File: /Library/Preferences/com.apple.screensaver.plist
Contents:
{
    loginWindowIdleTime = 4;
    loginWindowModulePath = "/System/Library/Frameworks/ScreenSaver.framework/Resources/iLifeSlideshows.saver";
}

File: /Library/Preferences/com.apple.ScreenSaverPhotoChooser.plist
Contents:
{
    SelectedFolderPath = "/Library/Preferences/imagefolder";
    ShufflesPhotos = 1;
}

File: /Library/Preferences/com.apple.ScreenSaver.iLifeSlideShows.plist
Contents:
{
    spansScreensKey = 0;
    styleKey = Flipup;
}

NOTES:

Different StyleKeys:
  • Classic - Images appear centered
  • Flipup - Images flip into place in front of previous pictures