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>

Edit: Updated link to Global policies can lock out admin accounts HT.

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. 

https://github.com/rustymyers/scripts/blob/master/shell/CertSignatureVersion.sh

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