In the App Store but Outside the Sandbox: Login Items – Artisan Technology Log: "If your app uses AppleScript to communicate with other applications and do awesome things, you might be out of luck in the secure new future Apple has in store for us all. We have an app in the Mac App Store called Ansible (also available for iOS) which needs to do exactly this. Fortunately, there are some ways to work around the immanent restrictions and poke holes in the walls of the new App Sandbox."

Nice tips on how to work around Sandbox "restrictions".

Labels: login item, sandbox

~/Library/Containers/Data/Library/Application Support/

The location of your app and your app's data files when running in the sandbox.

Labels: sandbox, security

redpig/patient0 · GitHub: "What is [patient0]? [patient0] provides a foundation for exploring trust relationships between the user, running processes, and privileges on OS X using runtime code injection and function interposition. In particular, [patient0] is a tool for performing widespread process 'infection' by making key applications, like Dock and Finder, spread the custom code. [patient0] is built on [libpatient0]."

How do you know that only your own code is running inside your app? AND, will codesigning checks be enough?

Labels: dylib injection, hacking osx, security

Securosis Blog | OS X 10.8 Gatekeeper in Depth

An nice article about the quarantine bit and how it interacts with Gatekeeper and Developer ID under Mountain Lion.

Labels: developerid, gatekeeper, mountain lion, quarantine bit

VIDEO:
http://youtu.be/KYGhay3yapk
CODE:
https://github.com/axelexic/SanboxInterposed

Labels: codesigning, hacking osx, mountain lion, sandbox, security

App Sandbox Design Guide: Migrating an App to a Sandbox

To support migration of app support files when a user first launches the sandboxed version of your app, create a container migration manifest.

SOURCE:http://goo.gl/VRhVo

If you App stores preference data in a location __OTHER THAN__ the standard location (.plist in ~/Library/Preferences), you will need a container migration

Labels: codesigning, gatekeeper, mac app store, sandbox

Building for the Mac app store

SOURCE: http://hartcw.com/francis/building-for-the-mac-app-store/

How to do a manual codesign of your app and installer bundle from the command line or makefile.

Labels: codesigning, mac app store, snow leopard, xcode

Mac App Store apps begin to comply with sandboxing rule ahead of deadline
Applications complying with Apple's sandboxing rules for OS X have begun to appear on the Mac App Store, with Pixelmator being among the first major offerings to meet the forthcoming requirement."

SOURCE: http://goo.gl/3F1jK

Labels: mac app store, mountain lion, sandbox

Call Me Fishmeal.: "The Mac App Store has been a huge boon to Mac software developers, but has an enormous flaw: it needs to allow developers to charge existing customers a discounted price for major upgrades."

I'm going to agree that some kind of system is necessary. Without new features to the Mac App Store, upgrades are always going to be full-priced with new SKUS or free via an existing SKU. Although I imagine in-app purchase could be used to effectively sell upgraded functionality to an existing customer. Not that the customer would like it, mind you.

Labels: downloads, mac app store

Why the Mac App Sandbox makes me sad | Naming Things: "Apple announced today that, starting in March 2012, all apps on the Mac App Store will be required to run in the so-called ‘App Sandbox’."

The value of the Mac App Store is a centralized clearing house for fun Mac Apps. The downside is that by centralizing __anything__ the security vulnerabilities are also brought into a peculiar focus.

I, for one, want the Mac/iOS platforms to be as successful as possible. Success means widespread adoption and widespread adoption means adopting modern security measures.

Labels: mac app store, sandbox, security

Bypassing iPhone Code Signatures - Jay Freeman (saurik): 

An interesting read.

Labels: codesigning, ios, iphone

MacTech | The journal of Apple technology.: "Code Signing - Get Used to It!

Digitally signed applications and you

by Scott Corley

What Is Code Signing?

So you're a computer. And you're not happy executing just any old software. No, you want to only run software that has been approved by someone you trust. How can you, the computer, tell the good from the bad?"

A nice gentle introduction to codesigning from mactech.com.

Labels: codesigning, tutorial

Proof-of-concept app exploiting iOS security flaw gets researcher in trouble with Apple | Ars Technica: "However, iOS 4.3 introduced 'sandboxing entitlements,' special exceptions granted on a very limited basis, to allow things like Nitro's JIT JavaScript compilation to work. In iOS 4.3 and later, MobileSafari has an entitlement called 'dynamic code signing.'"

Every sandbox has a skirmish, or it wouldn't be a sandbox.

Labels: codesigning, store receipt validation

sandbox — Secure Mac Programming: "App sandboxing

The really big news for most developers is that the app sandboxing from iOS is now here. The reason it’s big news is that pretty soon, any app on the Mac app store will need to sign up to sandboxing: apps that don’t will be rejected. But what is it?"

A very friendly description of sandboxing on Mac OS X from the author of Secure Mac Programming.

Labels: codesigning, developerid, mountain lion, sandbox, security, snow leopard

Checking Code Signing and Sandboxing Status in Code – Ole Begemann: "Can we do the same in code? Yes we can. With a lot of help from my coworkers Jörg Jacobsen (see his work on XPC and Sandboxing for the iMedia framework) and Christian Beer (who pointed me to the source code for the codesign utility), I wrote a category on NSBundle that can tell you for any application bundle: a) whether it has a valid code signature b) whether it is sandboxed and c) whether it was downloaded from the Mac App Store."

A really nice article and sample code about checking entitlements etc. The problem with using a category on NSBundle is that category methods are easily identified in the binary and can be hijacked.

Labels: codesigning, sandbox, security

Red Sweater Blog – Developer ID Gotcha: "For the upcoming Gatekeeper feature in Mac OS X 10.8, Apple will make it easy for customers to prevent software from running that has not been digitally ‘signed’ by developers with a certificate from Apple called the Developer ID certificate.

A nice handy post about how the default designated requirements generated by the build process don't always behave as expected on various flavors of X.

Labels: codesigning, developerid, gatekeeper, sandbox, security

Marc Liyanage - Blog - Developer - Mac OS X Application Code Signing
Benefits of Signing Applications on Mac OS X The latest version 10.5 (Leopard) of Mac OS X adds the ability to digitally sign executable code. I wanted to do that with one of our Mac OS X applications, the image uploader for our snapmania Online Photo Manager. Right now, the main user-visible benefit of signed applications is that accessing objects in the user’s Keychain no longer triggers this confirmation dialog after a new version of the application is installed:"

SOURCE:http://www.entropy.ch/blog/Developer/2008/02/11/Mac-OS-X-Application-Code-Signing.html

Here's a little codesigning information nugget from the interweb.

Labels: cocoa, codesigning, security

Preventing systematic piracy in Cocoa with Code Signing | CocoaLab

Here's a nice thread about the motivation behind using the Security.framework to enforce application bundle integrity.

Labels: cocoa, codesigning, mac app store, piracy

anchor apple generic and identifier "com.genkiyooka.developerID.mac.GK-DeveloperID" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = MQK467HD9A)

The code has been signed with following certificate chain:
NUMBER COMMON NAME
0 Developer ID Application: Gen Kiyooka
1 Developer ID Certification Authority
2 Apple Root CA


Labels: codesigning, developerid, gatekeeper, mac app store, receipt, security, validation

Gatekeeper Already Present in OS X 10.7.3, Available for Developer Testing [Archive] - MacRumors Forums: "By default, Gatekeeper is not enabled in Mac OS X v10.7.3. For testing purposes, you can turn it on by using the new Mac OS X system policy control command-line tool, spctl(8).Running the command 'sudo spctl' in Terminal will enable Gatekeeper on OS X 10.7.3."

A better description of enabling gatekeeper under 10.7.3 is here:
https://developer.apple.com/resources/developer-id/Developer-ID-Tutorial.pdf

In my testing under 10.7.3, the spctl commands did not work as described. But you can get it to work if you follow the macrumors post.

Labels: cocoa, gatekeeper, mac, sandbox

You may have heard about Developer ID and Gatekeeper, new security features coming in Mountain Lion. Essentially, this is an implementation of codesigning designed to secure 3rd party applications distributed over the internet.

Using Tighten Pro, you can inspect the certificate chain of any codesigned application. Last year, on stackoverflow.com, I wrote about the differences between the codesign on your app after you sign it with Xcode vs. your app after being delivered by the Mac App Store.

To summarize, the certificate chain looks like this after you sign it with Xcode and submit it to Apple for approval:

[LEAF] 3rd Party Mac Developer Application: "ME"
[AUTH] Apple Worldwide Developer Relations Certification Authority
[ROOT] Apple Root CA

After approval and delivery to the customer from the Mac App Store, the certificate chain looks like this:

[LEAF] Apple Mac OS Application Signing
[AUTH] Apple Worldwide Developer Relations Certification Authority
[ROOT] Apple Root CA

Under Gatekeeper and Developer ID, an application developed by you and shipped directly to customers after codesigning should look something like this:

[LEAF] Developer ID Application: "ME"
[AUTH] Developer ID Certification Authority
[ROOT] Apple Root CA

We've already tested Tighten with self-signed certificate chains and it works correctly as long as the leaf signing certificate has been signed by an intermediate authority (3 levels). It is possible to create your own Root CA and issue your own codesigning certificates. It can be done with Apple's Certificate Assistant (Keychain Access.app), but it is tricky due to bugs in Certificate Assistant.

Labels: codesigning, developerid, gatekeeper, mountain lion