Tag: security

Enforcing iOS Security Settings in Third-Party Applications

A while back, I was working on an  application for a client with a very specific requirement. Since it collected personal data, the application could only run on iOS devices that were protected with a passcode. This requirement, seemingly very simple from the client’s perspective, was a bit of a hassle to implement on the programming side of things. There’s no simple method on UIDevice to determine if a passcode is set, nor is there a way to force that programatically. In fact, there’s no way to force most things like that. The iOS device isn’t the programmer’s, it’s the user’s. Except when it isn’t.

One of the things that you can do is to use the iPhone Configuration Utility to make a configuration profile. These profiles can support a range of things, from requiring a passcode (or even an advanced, non-numeric passcode) to WiFi settings, VPN to CardDAV settings. Creating a configuration profile that requires a passcode, then installing that configuration profile onto the device is a no-brainer. But how do you ensure that the application will only run in that case?

Disclaimer: Before I go any further, you should know that since this was an in-house project, none of the code that I wrote made it into the App Store. Therefore, I don’t know if this is kosher in an App Store app, nor do I recommend this approach for that.

One thing that you can do is to include a self-signed certificate in a configuration profile. Those of you familiar with OpenSSL may be groaning as you realize where this horrible, horrible workaround is headed. I created a new certificate authority. With that new certificate authority, I signed a separate certificate that I had created. Verifying this certificate, then, requires that the verifying party accept the certificate authority’s certificate as valid. Well, since you can set that in the configuration profile, I did, along with the passcode requirement. Then, in the app, I bundled the certificate that I had signed with my CA.

When the app starts up, it attempts to verify the certificate. In the case where the configuration profile is installed and the CA’s certificate is in the system’s keychain as trusted, this is no problem: the certificate checks out and my app is free to go. If that validation fails, however, then I know that the certificate from the CA is in the system, so I know that the configuration profile is installed, as well.

Why this works for a passcode so well is that to install a configuration profile on a device without a passcode when the profile requires one is that you can’t install it without setting a passcode in the process. For the client, this was Good Enough, and the app shipped and worked properly. It’s worth noting, though, that the less the end-user knows about this process, the better. To circumvent the passcode restriction, all one would have to do would be to modify the configuration profile to still include the CA’s certificate, but not the pas code requirement. For that reason I can’t recommend this for anything like EMR or tax records, but for minor demographic information like we were collecting, this sufficed.

I realize this didn’t include any code, but the individual portions aren’t that hard, and I don’t have access to the original code so I’d have to re-write them all. Here they are in a nicely-formatted list for those keeping score at home:

  1. Create a new certificate authority with OpenSSL.
  2. Create a new certificate, then sign it with that certificate authority you just created.
  3. Create a configuration profile in the iTunes Configuration Utility with the settings you would like to enforce.
  4. In the “Credentials” section in the iTunes Configuration Utility, add your CA’s public-facing certificate to the configuration profile.
  5. Add the certificate you signed with your CA to your application’s bundle.
  6. In your application, verify the certificate you included.
  7. Distribute the configuration profile along with your application to end users.

Like I said, this is far from perfect. But when you’re working with an enterprise client who has Big Needs, this is one trick to keep in your back pocket when you’re up against a deadline.

Apple Surveying 32-Bit Third-Party Kernel Extensions

Today I noticed something new in my LaunchDaemons folder: /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist. It starts a Ruby script (/usr/libexec/third_party_32b_kext_logger.rb) when your Mac starts up that (and I could be totally wrong, as I don’t know Ruby) appears to use /usr/sbin/kextfind -system-extensions to identify third-party kernel extensions (e.g. kernel extensions for which the identifier does not begin with com.apple) that exist only in i386 or PPC forms. It makes sense why Apple would do this, as a move to 64-bit only would be in keeping with their typical attitude on leaving old hardware platforms behind, but this particular file is odd in that it’s in /Library/LaunchDaemons and not /System/Library/LaunchDaemons, where most Apple-created jobs are. Maybe this was a task given to a programmer new at Apple who was unfamiliar with the typical folder hierarchy on a Mac, but this smells odd. The only result I found for it in Google was this Apple Support forum post.
So, I did some investigation, and found that it uses the domain “com.apple.kexts.32bitonly” with the defaults command, and in my system log is this line:

/var/log/system.log:Mar 22 19:31:30 Jeff-Kelleys-MacBook defaults[3439]: \nThe domain/default pair of (com.apple.kexts.32bitonly, lastRan) does not exist

That is reason enough for me to believe that it’s installed as a part of Mac OS X 10.6.7, as that message signifies its last run time (the script quits if it’s been less than a week since it last ran). So, being the diligent former sysadmin that I am, I looked at the 10.6.7 update’s files, and didn’t see anything (else) of note. I don’t see a point in the script that reports this to Apple, so I don’t know if this constitutes a breach of privacy on their part, but it’s interesting nonetheless that it would appear that Apple is gauging whether or not they can leave 32-bit kernel extensions behind with minimal customer fuss.

Xcode 3.2: Using GDB as a Non-Admin User

New in Xcode 3.2 is an authorization setting that looks like this:

<dict>
	<key>allow-root</key>
	<false/>
	<key>class</key>
	<string>rule</string>
	<key>comment</key>
	<string>For use by Apple.  WARNING: administrators are advised not to
	        modify this right.</string>
	<key>k-of-n</key>
	<integer>1</integer>
	<key>rule</key>
	<array>
		<string>is-admin</string>
		<string>is-developer</string>
		<string>authenticate-developer</string>
	</array>
	<key>shared</key>
	<true/>
</dict>

The upshot of this is that if you aren’t in the _developer group in the local directory, you’ll have to authenticate as an administrator to use gdb or some of the performance tools. For the vast majority of developers on Mac OS X, who run as an administrator, this is fine, but if you’re running as a regular user, either for security reasons or because you’re in something like a lab setting, this can be a problem. To add a user to the _developer group, use the dscl command:

dscl . -append /Groups/_developer GroupMembership UserName

Replace UserName with the short name of your user account (or $(whoami)) and you should be all set.

If you’re administering Mac OS X in a lab setting, you can either create a LaunchAgent that handles this or a login hook. See the Apple tech note “Running At Login” for more information on login hooks. As an added touch, my login and logout scripts to handle this also remove all users from the group, like so:

dscl . -delete /Groups/_developer GroupMembership

If the GroupMembership key doesn’t exist, dscl will create it—and it doesn’t exist by default—so deleting it outright shouldn’t cause any problems.

Google Earth Now Available Without Automatic Updates

A while back I blogged about Google Earth’s stealthy, silent automatic update feature. That post continues to be pretty popular, so I wanted to share an update: Google has released a version of Google Earth, including the Web plug-in, that does not include the self-updater. On the download page, the EULA features this paragraph:

(b) Automatic Updates. The Google Earth software may communicate with Google servers from time to time to check for available updates to the software, such as bug fixes, patches, enhanced functions, missing plug-ins and new versions (collectively, “Updates”). By installing the Google Earth software, you agree to automatically request and receive Updates.

However, if you navigate to the advanced setup page, there’s a box you can un-check labeled “Allow Google Earth to automatically install recommended updates.” This box directs you to a separate download that does not include the updater. The EULA, however, does not change when you deselect it. I don’t think that really matters as much in the grand scheme of things, so I’ve really got to give Google some kudos here for listening to systems administrators and concerned users on this one.

Google Delivers Mac Google Earth API Plugin, But at What Cost?

UPDATE: Google has released a version of Google Earth (including the plugin) without the self-updating feature.

The Mac blogs around the ‘net are all abuzz today about Google’s release of a Mac version of the Google Maps API, but I noticed something funny when I installed it.  The plug-in is a standard Mac Internet Plug-In, meaning you can install it at either /Library/Internet Plug-Ins or ~/Library/Internet Plug-Ins.  So why does the install package prompt you for administrator credentials when you choose to install it into your home folder?  The answer lives at /Library/Google.

It turns out that when you install the plugin, the installer also installs a software update component, code-named “keystone.”  It installs the following components:

  • An application bundle at /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
  • A “Ticket Store” at /Library/Google/GoogleSoftwareUpdate/TicketStore/ — does anyone know what this does?  I sure don’t.
  • A LaunchDaemon that runs as root on demand, at /Library/LaunchDaemons/com.google.keystone.daemon.plist
  • A LaunchAgent (/Library/LaunchAgents/com.google.keystone.agent.plist) that runs when you’re logged in, presumably to fire up the daemon so you can receive updates without administrative privileges.

Interestingly enough, this software component is never mentioned by Google.  It isn’t an option you can deselect in the installer.  Even worse, the plugin’s uninstall instructions don’t say a thing about it.  This means that after you follow the plugin uninstall instructions, your computer is still checking in with Google’s servers to make sure that it’s up-to-date.  I’m reluctant to call this malware, but it sure seems like spyware, doesn’t it?  At the very least the installer ought to mention something.

Be cautious when installing this plugin onto any computer where security is essential.  Any software component that runs as root, such as the updater this installer installs, is another attack vector for intruders trying to get at your data.

For what it’s worth, the API plugin does work if you only copy the stuff in /Library/Internet Plug-Ins to a computer or to your user account, so it appears that you can still use the plugin in a secure environment, you’ll just have to update it yourself and not have Google do it for you.

I’ve also mentioned this on the official Google Group.