Your Apps and the Future of macOS Security

All right. My name is Pierre-Olivier Martel. I'm an engineering manager in the Security, Engineering, and Occupational Group here at Apple. And today, along with two of my colleagues, I am here to talk to you about some of the new security features in macOS Mojave and how you can make the most of it in your apps. I'll start by going over some of the high-level security improvements that went into the OS this year. And then I would like to dedicate the rest of this session to talk about some of the enhancements that we are putting in Gatekeeper.

A few years ago we introduced a feature called Systemic Security Protection to macOS with the goal to increase the protection of the operating system by making it so that platform binaries are protected from modification both on disk and at runtime. This year we are taking it one step further by enforcing additional code-sending requirements on platform binaries.

The system will now enforce the validity of code signatures throughout the lifetime of system processes and will automatically abort any process that deviates from its code signature or that attempts to execute any code that is not properly signed by Apple.

In addition to that, the system will monitor it - the dynamic loading of any libraries, frameworks, and plug-ins and enforce that - those objects also be signed by Apple. It's a mechanism that has been enforced on iOS for several years now, and we are excited to make this to be for the macOS. Of course, not that this only applies to the system. This does not apply - it does not apply to your apps. However, there still remains a few system extension points throughout the operating system that have not yet made the move to the app extensions model.

And those are technically considered to be platform binaries; OK, it's the plug-in loaders. So for those we are going to relax that policy, and the system will still allow these processes to load code that is either third-party signed or completely unsigned. So if you ship any of these plug-ins in your app, please make sure that you test on the developer preview and make sure it works properly. If not, please let us know. Next, I would like to talk about UI automation. The security model of a macOS, especially when it comes to user data access, relies on the user making security decisions for their self - for themselves. We deliberately captured those decisions, either via the user intent using the mechanisms like the open/save dialogs or drag-and-drop operations -- or by a user consent, with more explicit authorization dialogs or asking the user to make security configuration changes in System Preferences. As such, it's critical for the operating system to be able to differentiate between the user actually making these decisions and software driving the UI on their behalf. In the past we have made a few targeted enhancements to some of the system authorization dialogs to make sure that they can detect and block these synthetic events.

But these decision points have become so pervasive across the OS that we need a better model. In macOS Mojave, the system will only allow UI events to be dispatched by processes that the user has specifically configured to control the UI on their behalf and effectively impersonate them.

This configuration is made in the Security and Privacy Press pane in the System Preferences. And it's currently co-located with the existing accessing to the key list.

This is the list of APIs that will be impacted moving forward. They mostly fall under two categories. First, the kidlet Layer: IOHIDPostEvent and the IOHIDSetMouseLocation; and then second, at the CG Layer. If you attempt to post any CG event or if you create any CG event tab, we are now providing the Listen Only option -- effectively creating what we call a modifying tab. And the user will have to approve those processes as well.

And then next, we put a lot of focus of hardening Safari itself.

It is, after all, one of the most important Internet facing applications on the machine. So it deserves special attention. In Mojave, Safari, as well as every satellite processes that ship as part of it, it's fully sandboxed. If you are a web developer, this may potentially have an impact on your local development workflow due to the way that Safari now acts as its local resources on this. If you want more details, please check out the What's New in Safari and WebKit session this Friday.

And then of course, WebKit has been sandboxed for many years now. We put a lot of attention in auditing the existing sandboxes as well as removing any risky and unnecessary dependencies from those. For example, the web content process no longer needs access through the Windows server, to the dock, or to the network. If your app uses the system WebKit, then there is nothing for you to do in order to adopt this. You will automatically benefit from those improvements.

Next, I'd like to talk about Gatekeeper. So Gatekeeper has done a great job over the years in stopping widespread malware attacks on the platform. It's here. We would like to make it better. And we are focusing on three main aspects.

First, I invite Kelly onstage to tell you about a new security mechanism that puts the user in control over the way apps access their personal data.

Then I'll introduce a new security feature that you as a developer can adopt in your apps to increase their security and their transparency.

And then finally, I am sure you are all very impatient to hear more about the Developer ID notary service that Sebastian mentioned in his talk yesterday. So I invite Garrett onstage to tell you more about that. All right? Let's get started. Kelly? OK, thank you Pierre.

Hi, my name is Kelly Yancy. I'm with the OS Security Team here at Apple. And I am really excited today to tell you about the new user data protections in macOS Mojave.

Now in macOS High Sierra, these APIs -- -- prompt the user for consent before allowing apps to access their respective data. With these prompts, well-intentioned software can honor the user's preferences with regards to how they access their personal data.

Well now, in macOS Mojave, access to this data requires user consent -- even for apps that access the Backing/Store directly via the file system.

Now apps that currently use prescribed APIs to access this data should be well prepared. But as always, we encourage you to test your apps against the latest macOS release.

Now if your app does access the underlying databases directly via the file system, be aware that that may - that access may now block the calling thread while the operating system presents an authorization prompt to the user. And in a world where computers do billions of operations per second, it turns out people are relatively high latency. So you don't want to do that I/O in your app's main thread, or it may appear hung while the prompt is displayed.

So here is an example of code that accesses the user's pictures via the file system.

Now by default, the Photos app stores the user's Photos library in the Pictures folder.

So when this code traverses the user's Photos library, it may now trigger an authorization prompt for access to the user's photos -- where it would not have in macOS High Sierra. Now apps that traverse the user's Home folder could trigger multiple approval prompts, not just for photos -- for contacts, for calendars, and so on -- as many apps that traverse the entire file system, such as disk management or backup software.

So user can pre-approve such apps by adding them to the new System Application Data category in the System Preferences Security and Privacy pane.

By doing so, the user preauthorizes those apps to access all of their privacy-sensitive data without prompting.

Authorization can also be preconfigured in education or enterprise environments via MDM server as long as it's a user-improved enrollment.

When the user is prompted to authorize access to their personal data, it is important to communicate the purpose of that access.

Imagine that you just installed an app that you had never used before.

And the very first time you launch it, you saw this prompt. That's a tough decision. But we can make that decision easier by including purpose text, which makes it clear why the app is requesting access and what the consequences of declining that access would be.

Now your app can specify the text displayed in the authorization prompts displayed on its behalf by including keys in your Info.plist file. So here are the Info.plist keys for each of the APIs that we have been looking at.

Now you may notice that these are largely the same as on iOS. I want to call out one difference, and that's the Locations Services Info.plist key. This key is actually deprecated on iOS, but I assure you it is the correct key to use in macOS Mojave. So these keys will be required for apps linked against the 10.14 SDK.

So besides informing the user, these keys are also being used to inform the operating system that -- as the developer -- you intend for your app to access the user's personal data.

And should an app try to access the user personal data but not include the appropriate key and purpose string for that data, macOS Mojave assumes that that access was unintended -- and the app exits.

For compatibility, these keys are optional for apps that link - that target older SDKs.

So for example, if you have an app that still targets the 10.13 SDK and tries to access the user's personal data via one of these APIs, the app will not exit but will display a prompt lacking the purpose string -- like the first one that we saw a minute ago. So we still encourage you to include the Info.plist keys in your apps, even if you are targeting an older SDK, so that the user is better informed why your app is accessing their data. So in addition to these prompting categories, macOS Mojave also restricts access to this privacy-sensitive user data as well.

So the operating system will not prompt for authorization to access this data via the file system. Only the respective system apps or services have access to this data plus any apps that the user has preauthorized for system application data via the Security and Privacy Preference pane that we just saw. In addition, authorization may be preconfigured via MDM enrollment.

Another way that this data can be accessed is via scripting. So Mail, Messages, and Safari are all scriptable, exposing some of their functionalities automation by other apps.

Let's use Mail for an example. Mail's local database contains lots of personal information. It has the e-mail addresses of my friends, family, companies I do business with. And then there is the contents of the mail messages themselves -- my private correspondence, my shopping receipts, my shipping notifications, and my temporary passwords for services I forgot the password of. So the Mail app necessarily has access to its own local database.

And in macOS Mojave, other apps do not.

But since Mail can be scripted by other applications, we need to be sure that Mail only shares my personal information with my consent.

Because we want the user to be in control of how apps they have trusted with access to their data act on behalf of other apps, macOS Mojave will include prompts like this one, authorizing apps to control other apps.

Now the developer preview does not currently require authorization to automate other apps. But you can try this new protection out in a future preview. Only if the user consents will Mail accept being automated by other apps. So this applies to Apple events. But there are exceptions. And there are exceptions for Apple events that are not particularly privacy sensitive -- for example, opening documents in a default application, opening URLs in the default handler for that URL scheme, or opening other applications.

Finally, macOS Mojave brings every one of my favorite features from iOS.

User authorization for camera and microphone: I think I am going to decline this one.

So apps can - that's not a link in - apps can enumerate the camera and microphone hardware without user consent. But initiating capture requires user authorization.

And this applies to all devices supported by the built-in drivers.

Now your app can query the authorization status. And this is useful if you'd like your app's user experience to reflect user's previous decisions.

And this API provided by AVFoundation is the same as on iOS. And what's interesting is it doesn't just return a simple Boolean yes/no.

It actually returns an enumeration of four possible values. And I'd like to drill down on those because I think these are relevant. The first one, notDetermined, means that the user has not previously been consented for your app to access the camera or microphone.

So should your app try to access that hardware, the operating system will display a prompt at that time.

The restricted value actually means that the user cannot consent, that the hardware -- the camera or microphone -- has been disabled -- the parental controls or mobile device management. The denied value means the user has previously been prompted, but the user declined to give consent. They don't want your app to access that hardware. And finally, the authorized value means that the user has previously been prompted, and they did consent and your app can access that hardware.

So we believe it's important to prompt in context. And this is the reason why the operating system currently displays the prompts kind of just in time. At the moment that your app accesses the microphone of the camera, the operating system will present a prompt when necessary. And we feel that that's the right time because the user has the most context to understand why your app is accessing the hardware. But there are times where your app might want more control over the timing of those authorization prompts. For example, if your app opens a new window, and in that window displays frames from the camera or a visualization of the audio from the microphone, you might want to avoid displaying an empty window if the user declines authorization -- in which case it's better to prompt before opening the window.

So AVFoundation provides this API so that you can preflight that authorization. And I'd like to call out that this API is actually asynchronous. It takes a block with - that is called with a Boolean value of whether your app has access or not. So this is a little bit different than the enumeration that we just saw.

That block may be invoked immediately when you make - when your app makes this call. For example, if the user has previously already consented or denied access, the operating system already knows that answer and can immediately invoke the block telling you what that answer is. Similarly, if the parental controls or MDM server has made that hardware unavailable, the callback is immediately invoked with a Boolean value of fault.

But it's also possible that this callback will be invoked later -- possibly much later -- as a prompt is displayed while we are waiting for - and then only when the user makes their decision will this callback actually be invoked.

At that time we will know the Boolean "Yes your app has access" or "No it doesn't." So your app can include purpose text for both the camera and microphone.

And as with the other purpose strings, these are required for apps linked against the 10.14 SDK, and optional and certainly encouraged because they are informative for apps linked against earlier SDKs.

So to recap: Here is an overview of all the topics that we just looked at.

macOS Mojave does not solicit user approval for access to this user data. Only the respective system apps and apps the user has preapproved via the Security and Privacy Preference pane, or preconfigured the parental controls or MDM are permitted to access this data. And here are the categories of user data and devices the apps may access with user consent. Now the operating system -- macOS -- presents the authorization prompt to the user the first time the app accesses this data. And then it remembers the user's decision. And this is great for users because then they only see one prompt per app per piece of data. They don't get multiple prompts.

But as a developer, you may actually want to get pre-prompted so that you can test how your app behaves while the prompt is displayed, if the user consents, and if the user declines authorization.

So for that purpose macOS provides a tool, called tccutil, that you can use to make the operating system forget your previous answers to consent prompts.

So the next time that you run your app, and your app requires authorization, the operating system will re-prompt.

So this tool is provided for testing purposes only. Your app should not invoke this tool automatically, even in debug builds. So in summary, ensure your approval prompts are presented in context. This is important so that the user understands why they are being prompted.

And add Info.plist keys so the user understands what your app is going to do with the data and what functionality will be unavailable if they decline.

Access approval-gated resources from threads other than the main thread so that your app doesn't appear to be hung while waiting for approval.

And gracefully handle failure to access approval-gated resources in the event that the user does decline. But finally, when the user does consent, be responsible with the user's personal data. So these are the new user data protections available in macOS Mojave. Thank you, and I will turn the stage back to over to Pierre to tell you about the enhanced runtime protections. Thanks Kelly. So in the few years since the maturity of system integrity of protection to the Mac, a lot of you have asked us what you could do in your apps to adopt some of the runtime protections that we afford to the rest of the system.

Until now, there wasn't really a good story for this. Today, we are introducing a new set of runtime protections that you can easily adopt within your app.

It is a new opt-in mechanism that is available within the 10.14 SDK. It effectively sets a new security baseline for your app by enabling the full set of runtime protections that the system provides, and requiring you - requires you to opt to back into more risky behaviors or ideas. It is easily configurable with a new set of unrestricted entitlements. Unrestricted here means that these entitlements are available to everybody without any prior approval. It can be easily configured from within the Xcode UI. And then finally, it is fully backward compatible if you need to be able to deploy your app to older releases of macOS and its version. So as we add more features to this one time in the future, apps that have already shipped will not be impacted.

Now let's see what - let's talk about these new protections.

First off, code signing: When you opt into this new runtime, the system will enforce that every single executable page within your address space must be backed by the original code signature that shipped with your app.

It is a fine behavior for most apps out there. Of course it might be undesirable in some of these cases. So let's see how we can configure this. Let's say, for example, that your app has a scripting runtime for which you have high-performance requirements -- in which case, you'll most likely use JIT compiled code if you want to execute a runtime.

With this, you can use the first entitlement in this list. It gives you access to the new MAP JIT flag in the MMAP system call, which allows you to create what we call JIT regions, which are memory regions that are readable, writable, and executable. And if you have a poliacre system, where you might expect to be able to execute load plug-ins that are not properly signed or not signed at all, then you have to use the second entitlement in this list.

And finally, if your app needs the ability to modify its own code pages at runtime, effectively breaking its own code signature, then you will have to use the last entitlement in the system.

And note that the vast majority of apps should not need that functionality. But we still want it to operate anyway. Next, library validation: When you opt into the new runtime, the system will enforce the code signature of every library, framework, and plug-in that you dynamically load at runtime, and by default will enforce that. These modules have - these objects have to be signed by Apple and shipping as part of the OS -- or that they be signed with the same Team ID as the main executable that ships with your app.

If you have a plug-in ecosystem here and you need the ability to load objects that are signed by another team, you can use this entitlement to relax that policy.

Note that it still requires you to load signed code; it just can be signed by other teams. If you need the ability to load fully unsigned code, you will need to use one of the entitlements from the previous slide. Next, debugging: Apps that are opting into the new runtime cannot be debugged and cannot debug other apps.

If you need the ability to debug your app while it's opting into the new runtime, you can use the get-task-allow entitlement. Note that Xcode will automatically add this entitlement for you when you hit Build and Run from Xcode. So if you use Xcode as part of your local development workflow, then you don't need to do anything. Executable will also make sure that the entitlement is properly stripped from your signature when you do an export for distribution. If you don't use Xcode, make sure you don't ship your app with this entitlement unless you really need it. If your app is actually a debugger, then you will use the second entitlement in the list.

And then finally, in the few rare occasions where your app needs to rely on the DYLD environment variables to modify its BFU at runtime, then you can use the last entitlement in this list. And finally, your resource access: This runtime requires you to be transparent about the kind of data classing that your app needs to access. So if your app attempts to access any data that is part of one of the protected categories that Kelly described in his previous section, and you don't have the appropriate entitlement signed in your app, then the system will automatically terminate it.

We have entitlements that map to every single category that Kelly described.

But remember that just adding this entitlement is not enough.

You also need to add a purpose string if you are linking against the 10.14 SDK. And finally, it does not automatically grant you access to the data. The user is still in control of the final decision. So how do we enable this? Well, from Xcode you can go into Target setting in the Tap-ability tab.

There you will find a new hard and Runtime section, which you can enable.

We have checkboxes for every single of the entitlements that are previously described.

And then a few more comportable using the using the Command Line interface, then we can use the new runtime option in the codesign command. And in order for you to validate that you have properly enrolled and opted into this new runtime, you can use the dash-dash display option. And here, the things to look for are the runtime flag as well as the runtime version.

All right. Now let's look at the final piece of that puzzle and talk about notarized apps. Garrett? Thanks Pierre.

Hi everyone. I'm Garrett, and I work on the Trusted Execution Team here at Apple. Now my colleague earlier, Kelly, talked about one way we help protect users from malicious software by ensuring the user is always in control of their private data. I'd like to talk about another way that we protect users from malicious software. And that's by identifying and blocking malicious software so it doesn't have the chance to run. Now the Mac App Store is a great place for users to find and download new software. And people can confidently install apps knowing that Apple has taken steps to ensure they are not harmful. Now the Mac App Store is getting a lot of attention this year, and that's great. But we also understand that some developers need the flexibility of the Developer ID program.

Together, Gatekeeper and Developer ID have done a great job of preventing widespread outbreaks of malicious software. And today, we are making the Developer ID program even safer with the introduction of app notarization. Now app notarization is a process designed to help identify and block malicious software before distribution while still maintaining all the flexibility of the Developer ID program.

That means that you can continue to ship your apps the way you do today with the same capabilities that they have today. And the key to this is the Develop ID notary service. Now the notary service is an automated service that performs security checks of Developer ID signed content.

It's an optional extension to the Developer ID program, and it's not an app review. Starting today, developers can start uploading distribution-ready content to the notary service. And assuming that those applications, installer packages, and disk images don't contain any malicious software, the notary service will issue a notarization ticket back to your application.

That ticket can be stapled and then distributed alongside your application. And when Gatekeeper launches a notarized app for the first time, it can verify the notarization and provide a new first-launch experience. Now your development workflow prior to distribution is completely unchanged.

Now you may have heard, in the State of the Union, that this process will be required in the future. And while that's true, for now notarization is completely optional while we roll the service out and listen to feedback.

Before we move on, I want to make one important point. This is not an app review.

The notary service is simply performing a set of security checks to ensure that your content can be distributed safely. So what does this actually look like for your development workflow? Well here's a high level and simplified overview of the development process.

Over on the left, a developer iterates on an application local to their system building features, debugging, and signing with their Mac Developer certificate.

When the application is ready for release, it's signed with the Developer ID certificate, and a final test task can be performed.

After that, the content can be distributed directly to users -- who can run it -- or Gatekeeper can verify that it wasn't tampered with; and the user gets to run your application.

For this app to be notarized, only one additional step is required.

You continue to develop locally, just like before.

And once you sign it with your Develop ID certificate, a copy can be uploaded to the Apple notary service. Assuming that the Developer ID content doesn't contain anything malicious, a ticket will be issued back that can be attached to the content through a process we call stapling. And then the stapled content can be distributed just like before. And when it ends up on a user's system, Gatekeeper will verify notarization and provide the new first-launch experience. Now because this is a highly automated process, we are targeting providing tickets back within an hour. But we'll be working to improve the speed and quality of the service as we roll it out.

So let's talk a little more about those security requirements I mentioned earlier.

Well, first and foremost, no malicious software. If the security check finds anything malicious inside of the Developer ID signed content, it will immediately create a special kind of ticket called a revocation ticket and immediately notify the developer.

Second, all executables need to be properly code signed.

And this is important to make sure that when the application ends up on a develop - on a user's system, Gatekeeper can verify that it wasn't tampered with. And finally, all binaries must opt into the enhanced runtime that Pierre described earlier so they can benefit from the additional protections of the operating system without reducing their capabilities.

So assuming that you have an app that's ready for notarization, how do you actually go about uploading it? Well, it's built into the Archive and Distribution workflow inside of Xcode. So if you already use that, you are pretty much set.

Here you can see the Archive pane of the Organizer. And I have the Watch Grass Grow app already archived. So I click the Distribute App button on the right. I'll be taken to my distribution options.

I'll continue to distribute it via Developer ID just like I have in the past. And when I select that, I'll have a new option -- to upload to the notary service. Clicking Next will show a progress bar while the Developer ID content is uploaded to the notary service. And as soon as the upload is complete, you'll be notified that notarization has started. From here you can export a copy of your app to perform any local testing that you might want to do in parallel. And if you click Close, you'll be taken back to the Archive pane; and you can see that the status has switched to Processing. When notarization is complete, a push notification will arrive and Xcode will notify you that notarization is done.

Xcode will then automatically download the ticket, staple it to your content. So the next time you go into the Archive pane and click Export, you'll already have a stapled Developer ID notarized application. And when the user launches it for the first time, they'll see a new version of the first-launch dialog that includes your app's icon. Now we understand that not everybody uses Xcode's distribution workflow, although this Xcode works - dah. The Xcode workflow is available today in the preview. We have also built a set of command line tools to perform every step of this so that you can integrate them with any custom flows you have. And the first step is to upload a copy for notarization. Now the notary service accepts Zip files, installer packages, and disk images.

So if you have a bare application, you'll need to zip it up prior to uploading to the notary service. The tool for working with the notary service is altool.

Here you can see a command line indication sending the Watch Grass Grow image up for notarization.

Note that altool does require authentication, but you can pass in your credentials via Environment Variables or the key chain.

Once upload is complete, you'll get a UUID that can be used to monitor status of processing. But you can also turn back and pass the altool to check on the status of your notarization.

Here we see another command line indication of altool to just check the status of notarization. And then you can see here that notarization was complete, was successful. And importantly, there is a log file that comes back from the notarization service. This is a great place to check for any warnings, or it tells you exactly what was included in your notarization ticket. So you can make sure that everything in your package was notarized properly. And the last step before you distribute content is to staple your notarization ticket to whatever content you are going to distribute.

Now we have a special tool for that called Stapler. Now you can staple tickets directly to applications, disk images, and installer packages. And Stapler combines both retrieving the ticket and attaching it to the content in one easy step. Here you can see I am stapling the ticket directly to this image. After that's done, I can distribute the disk image, and the users will already get a notarized application. So as a quick reminder, in macOS Mojave, for non-notarized apps we'll continue to keep the first-launch dialog that Gatekeeper has always had for Developer ID applications.

For notarized applications, they'll get a new version of this dialog that prominently displays the app's icon. And if the user does manage to download software that has malicious content in it, the content won't run, and they'll be treated to this warning. Now this is not a new capability; macOS has always had the capability to block applications like this. But notarization does allow us to identify specific malicious content earlier and provides a much better experience than if a developer needs to revoke their entire Developer ID certificate. So that's how to build notarized apps and how they are going to help keep Mac users safer.

What can you do? Well, the notary service is available today. So feel free to start uploading your applications. And there is no reason to wait for your next app update. The service will gladly check your back catalog, too. So send in anything you have got. We are looking for feedback while we roll the service out. So if you have any issues with notarization, please come to the labs and we'd love to work through them with you.

Remember that signing issues, for now, will be warnings but are going to become errors in the future.

And when macOS Mojave ships later this year, Gatekeeper will be highlighting notarized applications to users. But then in a future macOS release, Gatekeeper will be requiring notarized apps by default. And that's all for Gatekeeper. So now I'd like to hand it back to Pierre for some closing words. Thank you Garrett.

All right, let's look at the key takeaways from this session. First, the macOS Mojave, the user is now in control over the way apps can access their personal data.

It means your app needs to be ready to handle their decisions -- first, because the user make take a while before they actually give you an answer.

Second, because they might completely decline the request. Additionally, please be transparent to the user about what did I need to access and why you need to access it, using new entitlements and purpose strings for this effect.

Also, make sure you request access to this data in context -- in the context where the user can actually understand why you need it and is more likely to grant you this request. We have a new higher runtime, which you can adopt in your app today.

It effectively increases the security and the transparency of your app. It does not take away any of the capabilities that you have today. It just requires you to opt into them. And finally, please help us make our users feel more secure and stop malware as soon as possible by getting your apps notarized. The Developer ID notary service is open for submission right now. If you need more information about this session, please check out our developer website.

We have a lab immediately after this section from 3:00 to 6:00 and then another lab tomorrow from 9:00 to 12:00. And finally, there will be another lab on Thursday dedicated to signing and distribution. Again, thank you very much for coming. Hope you have a great rest of the week. [ Applause ]