Cleaner Security Scripting

In 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.

2 thoughts on “Cleaner Security Scripting”

FTBZ says:

June 4, 2012 at 11:33 am

Hi, I noticed that our /etc/authorization file was reset with the 10.7.4 update. Perhaps this security tool prevents this kind of surprise ? We use Absolute Manage, so it’s easy to find computers that have been reset, but it’s still annoying. BR

LikeLike

1. The Mac Admin says:
  
  June 6, 2012 at 8:58 am
  
  @FTBZ I don’t think this method would make a difference. While it’s cleaner and easier, the security command still writes to the /etc/authorization file. To my knowledge, Apple has never supported modifications to this file. If you develop workflows that modify /etc/authorization, the best practice would be to keep good records and/or the script you use to make the change(s). If you have a management system that can detect when your changes get undone, you may be able to automate the re-application of your changes.
  
  LikeLike