Title: Gatekeeper and Developer ID Session 702 Perry the Cynic OS Security Architect Good morning, I guess still. I am Perry the Cynic. I invented Gatekeeper so I am here to tell you about it.
We have a lot of ground to cover. So let's get started.
What you will learn - What Gatekeeper is and how it works - How to control what can install and run on your Mac - How to sign your app so Macs will accept it by default - How to debug problems with Gatekeeper and Developer ID - Code Signing refresher I'm going to tell you what Gatekeeper is and how it works.
I am going to tell you how to use it to control what can be installed and run on your Macintosh.
I will tell you how to use Developer ID to sign programs so that other people let them install and run on their Macintosh.
I will tell you a bit about what problems you may have.
And because a lot of what I'm going to tell you won't make a lot of sense without it. I'm going to start with a code signing refresher.
We haven't a session on code signing for a while because it hasn't changed.
It's a fairly mature technology at this point. So, chances are, you haven't actually heard about it.
Title: Code Signing Refresher Code Signing in General - A code identification technology - Seal code to detect modifications after signing - includes bundle resources - Vouch for code with a digital signature - Tolerate intended code changes - Define and resolve code identity So this is a general code signing primer. This is not specific to Gatekeeper and it's just enough to get you going. There's a lot more, there is a lot more documentation on this. Don't be afraid read that.
Code signing is an identification technology.
It's about looking at a piece of code: an app, a tool, a library, and say "what is that? How can I identify it? How can I recognize it?"
Code signing itself is not necessarily about defeating or prohibiting anything. That's not its job. It job is to recognize.
Now, it's job is to reliably recognize. So if somebody changes the code after you sign it. We notice.
We put a cryptographic seal around this code thing.
You don't need to know how that's done. Unless you want to.
But, yes, we can tell if it's got changed after signing.
If this is an app or a framework with bundle resources we are sealing the bundle resources. So we can tell if the bundle resources got changed.
This is important because there are things in there like nibs that are basically free to write code.
And since anybody can sign code. It's a public API and a perfectly useful command line tool. We need a little bit more than just checking that it changed.
We also need to have something that tells us who signed this. So we are applying a digital signature that relies on a secret that only the particular developer has.
Whether it's Apple or you, doesn't matter.
Now one thing that code signing does, very well, is it can tell that code got changed. It can also tell you changed it that the developer changed the code and even though the bytes are all different it's meant to be the same program.
So that's baked into that logic of code signing.
I'll tell you a little bit about how that works.
This is all about identity. About what a piece of code is supposed to be.
Is it supposed to be Apple's Mail program is it supposed to be your utility.
Is it supposed to be a library or plugin you built.
That's identification. This is the one take away from this.
And then last but not least, this is supposed to work at runtime and fast enough that you generally don't notice.
That's actually a really good trick.
And there is a lot of code just to do that.
Er, yay, picture, thousand words, let's try that.
So, your code, your final code.
You've done everything to it that you can possible do.
You've stuck in all the localizations, you've polished all the resources.
You did all the NM editing and symbol removing and localization fixed and you added all the helpers.
It's done. You aren't going to change it again.
This is what you feed to the code signing machinery.
Now typically Xcode does this for you, but you can run the command line tool if you want to.
And we've said we need a secret. So here is a cryptographic identity.
It sits in your keychain.
You may have gotten from Apple through a developer program, but you could also have gotten it from a third party vendor.
That sold it to you for good money.
Or you can make it yourself. The machinery doesn't care.
A signing identity is a signing identity.
And it will work.
So, it will sputter a little bit and then it will put out a modified version of your program and it's signed.
This is thing you don't change anymore, because now we can tell.
This is how you ship to the end user, through the Mac App Store, or you mail to them, or though a website, or your hand them a USB dongle, we don't care.
The important point is that it doesn't change.
For all we care you can use can binary patch update mechanisms with really smart internals.
It doesn't matter as long as what you end up with on the end user system is the same bytes.
And at some point that program gets interesting.
It tries to run in the Gatekeeper environment. It asks for access to a keychain.
When it's already running, it wants to be a debugger.
There's more and more scenarios every year.
In any case, whoever controls that resource is feeding your program to the code signing verifier.
machine And that checks that cryptographic seal hasn't changed.
That no messed with it since it got signed.
But remember, you know, just checking for integrity isn't enough, because a bad guy can take your program, strip off your signature, change it, put on their signature.
Now it's their signature, but it's still intact, so we need something else that actually checks that this is the program as you signed it.
Not as somebody else signed it.
So we have this thing called a code requirement, which is essentially a simple rule. Things to check for.
Typically it checks for what's signed with your cryptographic identity.
Now where do we get these code requirements from?
Often, surprisingly enough, you get them from the program you are looking at because most of the time you actually don't care who made this program.
You care that it's the same program you saw before.
Think about the keychain for example.
When the program creates a keychain the system creates an access control list that says who has access to that item And the default value is the application that made it.
The keychain doesn't care who you are. The keychain care what program that is. All that it cares is that the program that comes along tomorrow and says, "I want that keychain item" is the same on that made it.
And remember I said we tolerate intentional changes.
So if the program comes along in two weeks is your new updated, improved version of the same program, it will still work, that's the magic.
Now, that code requirement gets stored somewhere.
So that it can be remembered later.
In the case of the keychain, it's in the keychain itself, the access control list.
Other subsystems have a database in the system. Gatekeeper does.
Sometimes, it's just a hardcoded role, you know: must be made by Apple.
This particular mechanism of pulling a code requirement from a program and remembering it is so frequent and so fundamental that we've given it a name.
We call it the designated requirement of your program.
It's essentially a code requirement that says, "How shall recognize you again."
You know. What should I check an imposter to see if it's you?
Now normally the designated requirement gets magically produced by just looking at your code signature, the code signature of your program and deciding what a good match means.
But sometimes that's not good enough, sometimes, you actually need to cook one yourself.
So when you sign a program, optionally, you can explicitly say, this is the designated requirement I want my program to have.
And this is important for some of you because this is what you do when you transition from one signing identity to another.
So keep that in mind. Designated requirements.
So, we have the cryptographic identity, the secret that you have, that proves that you are you, because you are not stupid enough to give it to someone else.
And we have code requirements that are used to essentially match this identity. They go together.
Lie key and lock Sometimes it's hard to tell which one's which.
So code requirements, these are actually the most important, non-obvious, part of this entire machinery.
So let me just give a couple of examples of what that looks like.
There is a text representation for these and a binary.
Mail.app the mail program that you all use on your mac.
- Mail.app anchor apple and identifier com.apple.mail this is it's designated requirement. Basically it says it was signed by Apple and it's name is com.apple.mail. That's all there is to it.
Apple says this is mail. You can't fake it because you can't sign like Apple.
There's a cage somewhere that they don't let you in. And Apple says this is the name so it's distinguished from Apple's Safari.
That's all there is to it.
Now if you made your own signing identity, like, you know, which keychain access, you can, it's free. Then you would end up with a code requirement something like this.
- Self-Made certificate anchor H"3b8ca..3e0fe7" and identifier "com.your.program" There's no anchor Apple because you're not Apple, instead it's anchor some hash which is basically the hash of the certificate you made yourself.
But otherwise structurally it's the same, it's, you know, this is the identifier you gave it, it's typically your bundle identifier.
And it was signed by this identity.
We don't really know who you are. We don't really need to know who you are, but we can recognize that particular cryptographic certificate.
And we know that you are holding the key to it and nobody else does. That's good enough.
May use the iCloud password anchor apple and info["Application-Group"] = "dot-mac" Here's another code requirement, just to give you an idea that we can do things here that aren't just identifying particular programs.
This one says that it's signed by Apple.
And it has an info.plist with a particular key called Application-Group and the value is dot-mac.
That's weird, you know. How did we come up with this?
Long time ago, there was this thing called dot.mac, before me.com, long time ago.
And that's around the time that code signing was invented.
One of the early requests was can't we just have something in keychain items that says anything that Apple says in the future has access to your me.com password, your dot.mac password, it will just work, we don't have to keep adding it to a list, so that's how it works.
Whenever Apple ships another app that it wants to have access to this password, it just gives an info.plist entry like this, you know, key["Application-Group'] = "dot-mac" and poof, access!
great Anything coming out of the Mac App Store looks something like this: - Mac App Store anchor apple.generic and identifier com.your.program and certificate leaf[field 1.2.840.1136188.8.131.52.9] anchor apple generic mean it draws to the Apple anchor and there is this identifier and it is what you'd expect, the bundle id.
And then there is this totally opaque weird certificate thing that basically says this how Apple, the Mac App Store, signs stuff.
You don't really need to understand, it's just, you know, some binary pattern inside a particular certificate.
But this is basically how this machinery works.
You just match things in the certificates that sign the program and you tack the name on.
You are pretty much done.
Just to jump a little bit ahead, Developer ID looks like this, and you can tell it's even more complicated, but the machinery is the same.
- Developer ID anchor apple generic and identifier com.your.program and (certificate leaf[field.1.2.840.1136184.108.40.206.9] or certificate 1[field.1.2...6.2.6] and certificate leaf[field.1.2...6.1.13] and certificate leaf[subject.OU] XYR4B7AAFB) You just take these little tests, you and and or them together with parentheses and negations and there you are.
If you pass this test, you pass the code requirement and if you don't you don't.
And that's all, you can settle down.
Title: Developer ID You all know about the Mac Developer Program.
You develop for the Macintosh.
You are signed up as a Mac Developer.
You pay your dues.
And you get your development certificates and your distribution certificates.
You use the distribution certificates to send stuff to the app store.
You develop with your development certificates.
And you've all signed little electronic pieces of paper that say you won't actually use those certificates for shipment outside of the mac app store.
I know some of you do, but you shouldn't.
So, what's Developer ID, what's new?
It's not actually a new developer program.
It's part of your Mac Developer Program.
If you signed up for the Mac Developer Program, you already can get Mac Developer ID certificates.
It's part of the deal.
You already signed the paperwork. There is nothing new to sign, you just have it.
You get new certificates through Developer ID.
Separate from the ones that you used to get for working with the Mac App Store.
We call them Developer ID certificates. It's not very creative, but well thems the breaks.
And those are there, explicitly, for distributing your stuff outside of the Mac App Store.
So it's complementary. We're not doing away with the Mac App certificates or the Mac App Store developer program but now for the first time, you got a way to take your program, and sell it through the Mac App Store, using the old method.
Or selling it anywhere else through Developer ID and it's all done with Apple certificates.
No more buying stuff from third parties, making your own stuff, wondering whether you did it right because we make it easy, that's our job.
We're trying to make it easy to make cool stuff.
Let's compare them.
If you go the App Store route, you distribute through the App Store, it's not your problem.
Apple puts them on a server and deals with the users.
If you distribute through developer ID it is your problem, because Apple won't do it for you.
You put it on your website and people download it. It's your website or your lease it from someone.
You can sell through a third party.
For all we care, you can put it on USB dongles and mail them through snail mail.
It's distribution is totally up to you.
Apple won't help you.
We won't advertise.
We won't bill for you.
Rules-wise. You all know. You all should know what the rules are for the Mac App Store program.
You've got the program licensing agreements You've got various appendices and attachments.
And you've got store review.
Everybody here has some scars from store review.
Developer ID doesn't have any store review because it doesn't have a store.
You sign your stuff. You give it to the user. The user is happy or he isn't.
There is nobody at Apple who looks at your program and says, "You shouldn't do that."
If you do something you absolutely, positively, shouldn't do, we'll let you know.
But it's an after the fact thing.
We'll find out. People will complain about you.
But there is no pre-filtering This is a big big difference.
I mean, that's good and bad.
Good it means that if you've got stuff that the App Store rules don't allow.
Developer ID will let you sell it.
It also means that the responsibility is totally up to you.
If you screw up and you ship something that erases somebody's hard drive.
There's nobody testing it for you.
Don't do that.
Different certificates. I've already talked about that.
And App Sandbox, for those of you who were in the previous session, and the rest of you, why weren't you?
The App Store now requires that you use the App Sandbox.
And that's good for the users. In many cases it's good for you, but it means that some of the programs that you can usefully sell can't go into the Mac App Store.
If you have a disc formatter, well, it's not going to go in the sandbox.
Developer ID can be used without App Sandboxing.
Now please don't misunderstand this.
You should App Sandbox your programs, even if you sell them through Developer Id.
Because the App Sandbox is useful.
It's useful for you, it's useful for your users, think of it as a parachute, an emergency brake.
A way to land more softly when the excrement hits rotating conveyance.
And if you sell the same program in and out of the App Store then it is really a good idea to use App Sandboxing on the Developer ID leg.
Because your program will behave differently if you don't App Sandbox.
And you will end up with users complaining that your program doesn't behave right.
Because the guy over there uses it from the store and the guy over here uses Developer ID. Don't get yourself in that situation if you can possibly avoid it.
And there's a little bene that we threw in because we can.
If you do sell your program both through the Mac App Store and outside through Developer ID.
And you follow the rules and you do what we tell you.
These two programs, through the magic of designated requirements and code signing, will looks the same to the system.
They will be the same program.
They will be signed differently, one will be Developer ID signed, one will be store signed.
but we did enough magic to make these programs looks the same to the system.
They can get the same keychain items, they'll be sitting in the same sandbox container.
They'll just be. They will have the same code identity.
So I talked about different certificates.
This is the old way, this is the store way.
You take your app and you sign it with your distribution certificate and you send it off to app store review.
And the app store reviews it and when they like it, they resign it.
With a special certificate that only Apple has.
That you don't have.
And that basically says, this came from the App Store.
It wasn't just sent to the App Store by some developer.
It actually came through, and out of the App Store and into the users system.
So it's a two-step. There's Apple in the middle.
Developer ID, same thing, but you sign with your Developer ID certificate, you put it on your website.
There's no Apple in here.
Again, direct, good and bad.
You directly go to your users and you are totally responsible for how that works.
Title: Using Developer ID Rule number 1: use Xcode 4.3 or later.
We mean this.
This isn't just, "Use our greatest tools because they have different windows and we are really proud how they blink."
There is special stuff in Xcode 4.3 and later that makes Developer ID work right in a number of circumstances.
If you use an older Xcode, this will not come out right.
And it will look like it almost works but not quite.
And that will be unhappy for you it will be unhappy for your users.
So Xcode 4.3 In Xcode there's a new section in the Archive panel that lets you archive to Developer ID And it just does the whole job for you.
It takes care of getting your developer ID certificate through the portal, it refreshes them, as they expire It signs the right way, it puts the right designated requirement in that gets that magic identity between the store and out of the store You can use an old Xcode or you can use your favorite makefile or shell script invoking code sign directly but you look all of that Xcode magic and you have to reproduce it somehow or it won't come out right.
I'm not going to tell you how to do that.
Go check the developer forum where there's a lot of discussion of "I hurt my big toe trying this."
It can be done, but it's significant extra work to get this right.
so try to avoid it if you possibly can.
Title: Demo Alright, really really short demo Just to show you how this looks.
This is a Cocoa app template straight out of Xcode with no changes except that I put some text in the dialog.
And you should all be familiar with the archive section which basically builds your program In a really short time And then you get the option to distribute it And normally you would be doing something like, I want to export it as an application.
Let's just leave the development signature in there that I have.
Now let's put it out there.
So good old Xcode.
And the same workflow except exporting to a Developer ID signed Application.
You get your choices of what Developer ID certificates you have.
If you have multiple ones, you get to pick it here and this one will take you on an exploratory trip on the developer portal to see what you can do there.
Other than that, totally same experience.
Let's give it a different name.
I've just Developer ID signed. That's all to it.
So if you use the Xcode workflow. There's very little change.
I used the same project. I used the same targets.
I didn't change a single setting on this Xcode project.
All you do is you archive to Developer ID You get the right signatures, you get the right everything.
It will just work.
Good for you.
Title: Managing Your Keys This isn't technically all specific to Developer ID But let me tell you anyway.
The first time you sign up for give me my developer ID certificate.
The system will make a set of cryptographic keys on your computer.
Because that's part of how this crypto machinery works.
It's made right there on your computer.
whichever one it is that you're asking for Developer ID.
And that's the only place where it is.
These keys are your secret.
They're supposed to be your secret.
Apple doesn't have them.
Nobody else has them.
That's the point.
But this means that you'd better back them up.
Because if you lose them, nobody can get them back to you.
There is no way to get them back.
They were your secret.
If you lose all of your copies, they're gone.
That's not good because, well, you can't prove that you're you anymore.
As far as code signing is concerned.
You can't make updates for this program anymore.
At least not easily.
So, don't lose them.
Xcode will actually pop up a panel that says, now would be a good time to make a backup and archive this.
So please do it.
And make sure you actually have an offsite backup of this There's a password in it, it's perfectly safe.
This may not be totally obvious: Developer ID certificates belong to your team.
Your account, you whatever it is that you think of yourself as you're signing up for the developer program.
You do not get one developer ID certificate per developer.
Or per group.
or per division or per project You get one.
Actually, a pair, but they act as one.
So Apple will give you a few, to help you with certain app situations, but you are explicitly not supposed to use those for using different signing identities for your different applicatons This won't work because after a couple, two, three, four, we'll cut you off and then you'll be sad.
If you're a large company where these kinds of responsibilities are important Access to your developer ID key will probably be controlled by some department and you'll send them the code and they'll sign it for you and for those of you who work open-source or just don't think about this secret means secret.
It means don't check those into some open source repository It's against the rules and it'll get your keys revokes And then, where would you be?
And if you lose control of your key oh my god, I had it on this laptop and I lost it in a coffee shop or I had it on this USB dongle and I don't know where I put it and maybe it isn't in my house If you think you lost control of your key talk to Apple because if somebody else gets a hold of your key They can be you.
So if they ship an application that erases everybody's hard drive it'll be your fault It'll be your good name that gets dragged through the mud You don't want this to happen so there's an email address: firstname.lastname@example.org You send them an email You send them an email if you even think it's possible you could have lost your key.
Because the consequences of not talking to Apple, and it just happening to you means that you're in an even worse situation when it comes out.
Title: Transition to Developer ID Well if you've got a new program, it's obvious: sign with developer ID, you're done, happy.
If you're currently shipping unsigned code, what the hell is wrong with you?
But it's easy to get out of that, sign with developer ID. It'll be a different program of course before you it didn't have any identity, But now it has an identity. It's a good one.
It's one that Apple gave you.
so you're good.
If you're currently shipping through the Mac App Store Use Developer ID to ship the same thing outside.
It'll just work.
You don't need a new project. You don't need a new target.
It's better not to have separate target.
Keep them together.
Use archive to Developer Id.
If you currently use a code signature that didn't come from Apple.
Whether you bought it from some certificate authority or whether you made it yourself.
You probably want to transition to developer ID I'm not saying youy must.
You can keep on shipping your program with the signature you got.
But, well, we'll get to Gatekeeper and what he will do to you.
If you want to transition to Developer ID, there is a couple of approaches.
There's cold turkey.
Let's just switch.
Tell the users and off we go.
That's easy for you.
It maybe'll not be so easy for your users.
Or there is an actual transition process that I'm not going to explain to you because it's kinda lengthy Check the developer forums where there's a FAQ for it.
Check the documentation on designated requirements because that's what you use to do that.
And if you're still confused come to the labs, talk to me I'll give you some hints.
Title: Gatekeeper Subtitle: What's on your Mac?
That's developer ID Everything with Apple certificates. Isn't that great?
It's not even extra money.
Now why did we bother?
Well, okay. It's nice to have a way for you to get all of your certificates for your code signing needs from Apple.
Single source shopping.
But of course, there's more to it.
Title: Download Quarantine We've always worried about programs that get downloaded from the Internet.
Because it's so easy to download stuff from the Internet and god know what they'll do to you once you install them and run them And over the years we've come up with ways to mitigate the risk a little bit One of them is called download quarantine Let me tell you about it in case you don't know what it is.
It's essentially a tag that gets attached to file We call it a quarantine flag That tag gets applied by the downloaders.
When you download something with Safari, unbeknownst to you, maybe, it puts a tag on the file saying, "This came from this URL, it was downloaded at this date."
But the most important thing is that the tag's on there.
It says this came from the Internet Let's pay special attention to it because Don't know what it will do to your computer.
When you take a quarantine file, a file that has a quarantine flag, on it and you copy it with the finder, or your favorite copy tool the quarantine gets copied along because everything's been modified along time ago to do that If you expand an archive that has quarantine on it, everything that comes out of the archive is quarantined You cannot shake that flag just with a normal set of operations.
If you have a quarantined disc image and you mount it everything in there looks quarantined.
So the point is that this tag sorta follows the data along Once it's attached.
So that at the point where you are trying to do something serious with it Like run an app inside of this disc image We still know that it came from the Internet And then we do things to the program because it came from the Internet And the classic thing is: "Hey, You meant to do that?"
It's just, click OK, it's fine, it's just a little speed bump In case that some website downloaded that for you and it's now asking you to open to do bad things to you Now, quarantine get's attached when stuff gets downloaded from the Internet If you make something locally it doesn't get quarantined If you have a file on there that you downloaded two years ago and you've worked with it It doesn't have quarantine on it That got stripped off when you answered that dialog And, quarantine does not usually apply to remote file systems either So if you AFP or SMB mount something from your file server there's no quarantine involved here.
Quarantine is from downloading from that big bad Internet in the sky Okay, that's quarantine, it's basically, "this came from the Internet. Let's pay attention to it."
Of course once we know it came from the Internet, there's a couple of things to do.
One of them is the classic Malware check that we all know about We know there are some things that are bad for you.
They are signatures patterns that we can look for, so we do.
And those get applied when launch services is asked to open something that has quarantine on it.
so that's how these two fit together.
And the pattern lists actually get updated potentially once a day.
There's a little preference checkbox that's on by default that basically says let's get an update every day.
To make sure that if bad viruses are trying to take over the Internet we know what they are.
And because a match on these quarantine flags is clearly a bad sign we have a rather nastier dialog that says, "This is bad for you. Please throw it away."
You may notice there is no open anyway button here, because, no really you don't know better.
If it actually fits our malware list it's bad for you.
and you should throw it away.
So,, that together forms what I might call the traditional way of dealing with possibly bad things coming from the Internet.
We have these lists of known bad applications and if something that you're trying to open or install matches those we yell at you.
Otherwise it's probably okay.
The problem of course is evasion.
If you If you're the guy who makes the bad app who tries to erase your hard drive, all you need to do it escape the pattern matcher.
You look at the pattern, you change your program so it still erases your hard drive but it looks different.
And then a couple hundred or a thousand more people get their hard drives erased Then the daily update comes out, matching that pattern and we keep playing until they run out of energy Which is not really a great way to do it.
So we are proposing to turn this upside down, Instead of working with lists of things we think are bad We're working with lists of things we think are good This of course means that if you aren't on the good list You aren't supposed to be bad, you're just, we don't know about you.
You're not signed in the way that gives us the warm fuzzies So you're not on the good list.
The problem here of course is that we all hope there's a heck of a lot more good programs in the universe than bad programs.
And for this machinery to make any sense it has to catch substantially all the good ones.
That's the hard part. That's why Gatekeeper isn't 10 lines of code.
Gatekeeper is built into the operation system.
It's a system facility it's always running.
You can't excise it, it's not an option.
It's behavior is driven by a set of rules, configurable rules.
So this is not a bunch of code that knows what it means to be a good program It's configurable And it probably won't surprise you very much to hear that the matching is done through code signatures.
And code requirements.
That's why I told you about this stuff earlier.
Essentially each rules says that if it is code signed And the code signature looks like this, then it's okay.
And of course if no rule matches then we don't know.
Because it's rule driven it's highly configurable That's important, but we all know that 90% of all systems never change their configuration.
And just like the malware checks it's driven by quarantine So right now, Gatekeeper only looks at a file if it has been downloaded from the Internet and it has been quarantined.
This should make you relax a little bit, it means that the programs on your hard drive that you've been using for years are not suddenly going to be viciously attacked by Gatekeeper And stuff that you build with Xcode Gatekeeper isn't going to look at it and say, "this is a foreign body on my system, I'm going to... yeah, no" Remember we built this thing, just 15 minutes ago.
And I put it into this directory mysteriously called sites.
Let me just compress this.
So this is testy, which was signed with a normal, non-developer ID certificate.
And here is test-device which we signed Well, why is called sites?
I'm going to use safari to download these archives I just made Because downloading is the easiest way to actually attach quarantine to it.
I just turned on the web server on that system So let's download that, and let's download that And here it goes into Downloads Okay, so we have downloaded this You can't tell from looking at it in the finder that it has quarantine on it.
Because quarantine is supposed to be this internal thing that you don't need to worry about And well let's see what happens.
Oh, oh no, it can't be opened because it's from an unidentified developer Notice it doesn't say it's from an evil developer.
It doesn't say it's from a developer we don't trust.
It doesn't say it's from a developer who didn't pay We just don't know who that it.
So we're not being judgmental here.
but remember that the idea of Gatekeeper is that if it's not on a good list then no.
That's the price we pay here.
Everybody who wants to be on that system needs to be on the good list.
Let me show you the UI really quickly so you know what gets switched around here.
In the security and privacy section of course, In the general section, here is a new part.
That says, allow applications downloaded from: If you've played with the developer releases you've already seen this.
And you get at the macro level outside you get these three settings.
The normal one is Mac App Store and identified developers And anytime the system talks about identified developers or identified programs I want you to understand this means there's a rule in Gatekeeper that stays this is okay.
That's what identified means.
It doesn't really mean just Developer ID because the rules can be changes.
By default it means.
And of course we'll accept anything from the Mac App Store because if you can't trust the Mac App Store, who can you trust.
If you are, if you the user, this is not for you the developer to switch around.
This is for the administrator of that system If you don't trust those developer ID things because god know what they'll do After all they could erase your hard drive if they happen to be a disc formatting tool You can switch to Mac App Store Only and that disallows Developer ID. Make Developer ID useless on that system. In a sense.
We don't expect that to happen a lot.
And then of course there is anywhere.
Which essentially turns Gatekeeper off.
With very few exceptions, if the system is in the anywhere state it behaves just as if Gatekeeper wasn't there.
That's not a good thing.
Because we think Gatekeeper is useful and helpful to the user.
So we would appreciate it if you didn't tell your customers to immediately switch off Gatekeeper because your program can't be bothered to be developer ID signed.
And, yes, you get this little lecture here if you try to turn off Gatekeeper that says you shouldn't do that.
That was unidentified developer.
so the developer ID signed version You still get a dialog and if ever you've used a Macintosh before with anything downloaded, you know that dialog, that's the this came from the Internet, you haven't opened it before, are you sure you want to do this.
this dialog doesn't go away.
Gatekeeper is sitting in there are an additional security layer.
This dialog is fairly harmless.
Assuming you actually meant to download this program and run it.
Let me show you one more dialog you can run into.
You'd think that this is bad.
It tells the user, we don't want to run this here, we don't know where it came from.
But this is not the bad dialog. It's a relatively harmless dialog.
Let's go into that bundle and make a change to the program doesn't really matter what we change because the entire info.plist is of course sealed down by the code signature.
Let's save that.
So, basically, I hacked your program.
Oh look now it's damaged and can't be opened and you are in the bad case.
Oooh. Don't touch this program, throw it away.
So this is that bad dialog if your users see that dialog about one of your programs it means you screwed up the code signing or somebody hacked it after you shipped it.
Maybe your distributor.
Maybe a hacker, who knows.
This is dialog you don't ever want your users to see.
So what does Gatekeeper apply to.
obviously code, Applications, not just Applications, tools, in addition, Gatekeeper applies to installer packaging Because installer packages have their own security things, I mean yes, they install applications that you can process as applications later, but they also have things like pre-install scripts and post-install scripts that can do unspeakable things to your system.
particularly if you enter your admin password because then they can do it to the entire system So installer are dangerous too, so we apply Gatekeeper and we apply signatures to installer packages too.
There's two kinds of installer packages, flat ones which is a single file and bundled ones.
You can't actually sign bundled installers which means you'll have to use flat installers to developer id sign your installers If you have, if that confuses you, talk to the installer people or the Xcode people, I'll tell you later where to find them.
Gatekeeper also applies to certain classes of documents that the system thinks are dangerous.
Shell scripts. Certain things that you may not think are dangerous but we know better about.
Like safari archives because they have code in them Sl Gatekeeper can also sappily to documents and you get the same dialog that says not from a recognized developer and the same ways of processing that But sometimes you want to ship a bunch of documents, you can't really code sign those.
That's a problem with them, because they're documents, not code.
So if you want to ship a bunch of dangerous documents to a user from some reason and they understand this and they want those dangerous documents.
we invented a new archive format It's a very straight-forward simple one, we call them "chip" files. XIP is the extension. Just like flat installer archives those can be signed.
And if you put a developer id signature on a XIP archive then all of the stuff inside is marked okay.
So this is the way you take dangerous files, if you absolutely have to ship them to your users.
And get them through Gatekeeper.
What i just said.
So, Gatekeeper is driven by rules.
And what gatekeeper accepts and what it doesn't accept is entirely a function of what rules it has.
And what Gatekeeper accepts and what it doesn't accept is entirely a function of what rules it has.
Read the man pages, I'll tell you what they are, for details.
It can be fairly complicated.
These rules are fairly flexible.
They're meant to do a lot of things.
One thing to understand is that there are different rules for execution and installation.
so if you a look a particular Gatekeeper role and you stare and you go from everything he's told me this should apply to my program But it doesn't.
It totally ignores it.
it probably is an installation rule and you are trying to whitelist a program and you are trying to whitelist an installer.
Different types, totally separate.
The outcome of Gatekeeper evaluations is cached, because these evaluations - you go through all these rules, you test them one by one if you've got a lot of rules this can get kind of slow.
So we cache the outcome, which is a good thing and you don't need to worry about it usually.
Because we flush the cache at the right times.
If you start playing around with this by copying files around and "gee, I wonder what happens if I do this?"
then sometimes you need to remember that there's a cache and if you go behind the back of the mechanism by messing with files directly the cache may still hold old data.
So, keep that in mind.
Let's go back to that picture for code signing.
But this time let's talk about how this specifically works with developer ID and with code signing.
So here's your final code. It's the same final code.
The same project. The same targets. Everything.
You haven't changed a thing.
You feed it to Xcode Did I mention Xcode 4.3 or later? Very good for you.
And when you do the archive to developer ID part, behind your back Xcode is starting to code sign it actually takes the build output from the archive step and it resigns it with your developer ID signature.
Which of course it gets from your keychain from where it has fetched it from the developer portal from Apple All done by Xcode, you don't do a thing.
This just works.
You get the output of the archive step and that's where you come into play. You put it on your website.
You send it over to your distributor.
You burn it on a DVD if you really want to be stone age.
And it ends up on the end user's system and cause we assume for the sake of argument that this was downloaded through a website server it is now quarantined See how the pieces start fitting together?
So you I've got a quarantined installer archive or application.
Depending on how you ship it.
And if you are trying to install that installer archive or first launch this applications because it is quarantined Gatekeeper gets involved Launch Services does that.
So now Gatekeeper is looking at this program and feeds it to the code signing verification machinery.
And it has a database.
/var/db/SystemPolicy In case you care.
That's where all the rules sit.
It basically just runs through the rules and each of the rules has a code requirement And it just matches them up one by one.
In a particular priority order.
So that's where the code requirements come from.
in the Gatekeeper case.
They come out of the rules.
We run through and the first rule that matches has an outcome.
Usually it's this one's okay.
You can actually make a rule that is: "this one is so not okay, I never want to see it again."
That's how code signing works in the case of Developer ID working with Gatekeeper.
So we talked about these rules.
And if you are happy with default, you don't do anything about them They're just there and they work. Good.
Sometimes you want to change them because it's your Macintosh and you want it to accept something that isn't developer ID signed but you want it anyway.
The default. Anything coming with the system of course is okay.
Anything coming from the Mac App Store is okay.
Anything coming with Developer ID is okay.
You can make individual exceptions.
There's UI for that.
You may have noticed, those of you with the eagle eyes, when you try to turn off Gatekeeper in the system preferences it actually tells you, "Don't turn me off. Do that instead."
That's your first hint.
Now if you happen to be using OS X server or you are really good with a binary editor, you can make a configuration profiles that actually push Gatekeeper rules.
This is new in Mountain Lion.
So if you have a bunch of systems whose people trust you so they will actually double click on configuration profiles that you send them, you can just package up a rule that says "my programs are fine" or "this program is fine."
send it to them and say "please double click that." And if they do it adds a rule and they're fine.
Also if you want to be more formal about this and you're using workgroup manager, it has learned in Mountain Lion, to push Gatekeeper rules out to all of the managed clients.
That's a really nice formal way of controlling which programs are allowed to be installed on systems that are part of your workgroup.
And if everything else fails and you know exactly what you want and you don't mind using terminal.
There's a new command called spctl. System Policy Control Program.
It lets you edit those rules directly and explicitly and with a lot of detail.
So, if you're the tinkering kind, this is your new buddy.
So, it's built in to Mountain Lion.
It's part of Mountain Lion.
It's on in Mountain Lion.
The default value when you install a new system is Mac App Store or Developer ID.
This is going to hit you and your programs as mountain lion deploys.
It's also been back ported to a large extent into Lion.
In Lion it's currently dormant.
It's there but the UI, the major, master UI that lets you turn it on or off is hidden.
And it's off by default.
So, you don't notice it.
The users don't notice it.
But, it's there, in case you want to test with it.
And you don't have a mountain Lion system handy.
You can actually get instructions from the developer website.
There's a defaults write that makes the UI appear and then you can turn the feature on and play around with it.
No Mountain Lion required.
This also means that users who know what they're doing and they care, may turn this on on you.
So it's possible you will get complaints from users on Lion saying your program doesn't install here because you didn't get with the Developer ID program.
Don't let that happen to you.
How do you test it?
Well it's pretty obvious by now.
You sign your program with Developer ID You put it on a web server You download it.
You can mail it to yourself to if your mail server actually accepts attachments big enough.
You just need to get quarantine attached to it somehow.
And you double click on it in the Finder and you watch what happens. I showed you.
Either it'll launch, you're successful, everything's cool.
Or you get this unidentified developer dialog that's not so cool, it means that you thought you were developer ID signing but you really didn't and something's wrong.
Or you get this dialog that says "Your program is broken and please throw it away" which means you totally messed up the signing.
If you run into trouble Well it's time to break out good old Terminal.
There is the new spctl command that is the Swiss army knife of Gatekeeper rules, it also lets you enable and disable Gatekeeper from the command line.
In particular there is a access option that lets you directly ask Gatekeeper, "what do you think of that file?"
That doesn't require quarantine. It's a direct call.
Basically, "Hey, Gatekeeper, what do you think?"
It just looks at it and goes, "Okay" or "I'm not going to allow this."
Calls the same API that Launch Services does when you are going through the double click path so you're directly asking the same oracle.
And there's spctl add, which actually lets you add a rule.
So this is what you tinker with if you want to tell Gatekeeper that, stuff like that is okay on my system.
But of course, there's a remove and lots of other things.
Alright, there's the good old codesign command With you since about 2005.
It's there so you can sign code, but Xcode does that for you.
You will just use Xcode 4.3 or late and you will be happy.
It's good for you.
But you can also ask codesign to verify for you and that's very happy.
Because if you give it enough levels of verbosity it will actually tell you in many cases, what's wrong with the code signature.
In particular, it will tell you if you stealthily tried to add or removes files, resources, after you signed.
Which is something that sometimes happens and it should so it'll say "this file there, you shouldn't have added that."
There's also codesign display, which basically tells you everything that's in the code signature.
It's kinda handy sometimes.
In particular it tells you what certificates a piece of code was signed with.
A really easy way of seeing if you're actually looking at a Developer ID signed program because the word developer ID is right in there.
And if it isn't then you didn't and you just signed with the wrong thing.
There is a very obscure program called csreq that I'm just mentioning here for the first time ever.
This is a little editor for code requirements.
If you play around, or mess around, with code requirements, take a look.
To sign installer archives. We are telling you to use the productsign command.
The productsign command is know to do okay with Developer ID signatures.
There is a surprising number of different programs that can sign installer packages.
And some of them do better than others, so we're telling you to use the productsign command.
And of course, there's the shiny new xip command which exists solely for the purpose of creating xip archives which you can sign in the process of making them.
And then you can send them out to get those dangerous commands through Gatekeeper.
And, that's it.
Paul Danbold is the Evangelist who is always so sad that none of you give him a call.
So he is your first point of official contact.
If you have any questions complaints or other contact requests.
There is an entirely new section in the developer documentation on Developer ID.
Which really should be read as Developer ID and Gatekeeper. It contains a tutorial.
It contains some background information.
Some technical information.
Think of it as your jumping off point on this entire thing.
It's there. If you haven't read that, don't complain first.
There's also a dedicated forum in the Apple Developer Forums on Developer ID and Gatekeeper where you know how the developer forums work.
You are talking to each other and an Apple says, "No, that's wrong."
But there's already some really useful information there, so before you start making up theories on how this stuff should work for you.
Read the Developer forums on Developer ID because it's useful stuff.
And contribute. You too can say, this did not work for me.
Related Session I keep telling you to use Xcode, so there's a session on Building, Archiving and Submitting your App.
This is the session that talks about Xcode and how you use it to bundle up your stuff and get it ready for sending it off.
Both to the App Store and through Developer ID.
They will actually show you the Developer ID path and talk about it in a little detail.
So if you're having questions about the Xcode side of this, this is the session you want to go to.
You missed the Sandbox session just before this one.
But we made you a repeat on Friday. So if you missed Sandbox you've got another chance.
Summary What have I told you.
Gatekeeper is about helping the owner of a Mac control what goes there.
This isn't about some people telling other people what they can do with their Mac.
This is about controlling your own Mac's destiny.
Gatekeeper is a tool for that.
It happens to have a preset when it comes out of the box that says, "By default, it's okay to install stuff from the Mac app Store, and stuff that's signed with this Developer ID thing.
So that's what Developer ID is, primarily.
It's your way of getting your stuff through Gatekeeper on default configurations Gatekeeper is real and when Mountain Lion ships, it'll be right there in your face.
If won't yell at you if you don't install anything that isn't Developer ID signed.
And, yes, you are going to run into Lion systems that have it on two, so be prepared for that.