Advances in macOS Security

Good morning, everyone. And thanks for joining us today.

My name is Garrett, and I work on the security engineering and architecture team here at Apple. And today, we're here to talk about some of the advances in security coming in macOS Catalina.

Here's a quick agenda for the talk. We're going to talk a little bit about the security principle of defense in depth and how it's applied in macOS. Then we'll dig into two very different parts of the macOS security model, Gatekeeper and user privacy protection.

So let's get started with Defense in Depth. Now, with a product as complex and with as many use cases as macOS, it's-- there is no single technology or feature that can deliver perfect security alone.

So instead, macOS is designed with many different layers of security. Each designed with a specific purpose or goal.

And every year, we improve the technologies and policies at each of these layers to help keep you safe. And this is an application of the principle of Defense in Depth. And the goal is to ensure that one layer of security failing doesn't defeat the entire security model of the system. Instead, we rely on multiple layers of protection with different properties. Some layers are designed to delay the advance of an attacker, others to reduce the attack surface of a component, and some to create choke points that make it easier to defend a specific asset.

And today, we're here to talk about two very different layers of security in macOS.

First, we'll talk a little bit about Gatekeeper, which is an important outer layer of security, designed to prevent malicious software from ever running on your system in the first place. Then, we'll talk about user privacy protection, which is designed to ensure that even if malicious software is able to get around Gatekeeper, it doesn't necessarily have access to your most sensitive data and resources. So let's talk about Gatekeeper.

When Gatekeeper was originally introduced, along with the Developer ID program, its goal was to prevent the widespread-- prevent the outbreak, a widespread outbreak of malicious software. But over the years, its goals have broadened a bit. And now, it's designed to protect users from running malicious software while leaving them in control of what they run on their Mac.

Now, exactly how it does this has changed over the years too. And while there's a lot of nuances, Gatekeeper's intent can generally be boiled down to a few simple questions. So let's talk about how Gatekeeper achieves this goal today.

There's four things that we think of as part of a Gatekeeper scan.

The first is a malicious content scan to ensure that there's nothing known malicious in the app it's about to run. Second, there's a signature validation, to ensure that the app hasn't been tampered with since it was signed by the developer. Third, there's an identity validation. And this is what we use to enforce the computer's local security policy. If the user has selected that they only want to run software from the App Store or identify developers, then we don't want to allow something that's been signed by anyone else, or that doesn't have a signature at all. And finally, there's a first launch prompt, which is meant to ensure that the user actually wants to run this application. Now, we can't talk about what Gatekeeper checks without talking about when Gatekeeper checks it. And in macOS Mojave, Gatekeeper runs its scans on the first launch of quarantined software launched via LaunchServices. Now, to understand that a little better, we need to dig in on what quarantine means and what it means to be launched by LaunchServices. So let's jump into that.

Quarantine is a technology built into macOS to mark files that have arrived from somewhere else off of the device. When you download a file in a web browser or when someone sends you something via iMessages, or if you get an AirDrop, those files all get quarantined.

Additionally, macOS will add metadata to that file about where it came from. So when we present a first launch prompt, we can give you more contexts about where that file came from.

Now, quarantine is an opt-in model, which means that apps have to opt in to quarantining the files that they place on disk. And that generally means that when an app downloads files in the background as part of, for example, a self-update, those files generally never get quarantined.

The exception there is if the app is App Sandboxed. Because quarantining files is the default for Sandboxed applications. So that helps you understand a little bit more about what files on a system will get quarantined. Now, let's talk about Launch Services.

Launch Services is a framework for finding and launching applications. And it's generally responsible for most of the ways that you think of launching applications on your Mac.

For example, when you open an app in Finder or the Dock that will use Launch Services.

If you use the NSWorkspace APIs, those generally go through Launch Services also.

And when apps get open via document handlers or directly through URLs, that all goes through Launch Services. Now, for the rest of the presentation, I'll use this Finder icon when I'm specifically talking about something that goes through the Launch Services path.

But there are also many ways of loading code that don't go through Launch Services. Some examples that are not exhaustive, include using NSTask to start a process, or the exec and posix spawn's calls or loading a library into your process using the NSBundle APIs for loading or dlopen. And for the rest of the presentation, I'll use this terminal icon when I want to refer to loading code off of the Launch Services path.

Now, let's quickly summarize everything that we've learned about Gatekeeper in a format that will make it easier to talk about what's changed this year. So here, we can see Gatekeeper's behavior and macOS Mojave that on the first launch of quarantine software on the Launch Services path, Gatekeeper will perform a malicious content scan and a signature check to ensure that there's no known malicious content and that the application hasn't been tampered with. Then it will perform a local policy check where the default is that it must be signed with the Developer ID certificate or by the App Store.

And finally, it will present the first launch prompt to the user, so that the user must approve the application. Now, starting with the latest release of macOS Mojave 10.14.5, the default policy was changed slightly such that new Mac developer certificates required their software to be notarized to pass Gatekeeper, which brings us to the first improvement in macOS Catalina. We're expanding on this policy such that all new software requires notarization. And in this case, new means that the software was signed or built after June 1st, 2019. This means that all existing software will continue to pass through Gatekeeper as is, with just a Developer ID certificate signature. But that all new software must be notarized to pass Gatekeeper.

Now, the next improvement that we've made in macOS Catalina is that Gatekeeper is going to be expanding to enforce the same policy on all quarantine software.

And that means that regardless of how the software is loaded, if it's quarantined, it must contain no known malicious content, it must not be tampered with, new software will require notarization. And the first launch policy will be slightly different, where we won't be requiring first launch user approval for standalone executables or libraries, but all bundled software will show first launch prompt.

So now, Gatekeeper has been expanded to scan and enforce policy on all quarantine software.

And that brings me to the final improvement in macOS Catalina, Gatekeeper will be further protecting you by ensuring that all software gets a malicious content scan. And that means that regardless of whether software is quarantined, and regardless of how that code is loaded, if any known malicious content is found, it will be blocked and the user will be alerted.

So this is a summary of all the ways that Gatekeeper has been expanded to help protect you in macOS Catalina.

But it's important to keep one thing in mind. Our goal is to make every Mac user safe by default, but not to prevent you from running the software that you want to run on your Mac.

And that means that there will always be a way to run a specific piece of software that you want to run on your system.

Now, I talked a little bit earlier about how every year we're continuously improving the technologies and policies that we have at every layer. So I'd also like to take a minute to talk a little bit about what's next for Gatekeeper. Now, we have a really big goal on the security engineering team. We want to make macOS just as secure as iOS, while still maintaining all the flexibility that you've come to expect out of your Mac.

And that presents some really interesting challenges.

But one thing has become really clear, the security of the platform has become increasingly reliant on the validity of code signatures. And this means that if an app has no signature, it's impossible to detect tampering. And further, if a bundle signature has become broken at runtime, it's very difficult to differentiate malicious tampering from mundane tampering when in out modifies itself at runtime.

And in a future version of macOS, unsigned code will not run by default anymore.

And to get there, there's a couple of things that you can do to help improve the security of the platform.

First, sign and notarize all the software that you distribute, even if it doesn't get quarantined today.

Second, don't break application or bundle signatures at runtime.

If you do need to update an application, make sure that it results in an application on disk that is properly signed and notarized still.

And finally, remember that loading code can fail. If you try to load a quarantine library or process and the user chooses not to run it, that will fail and ensure that your apps gracefully handle these failures.

So these are all the ways that Gatekeeper has been expanded to try to prevent malicious software from ever running on your Mac.

Now, let's bring up Kelly to talk about advancements in user privacy protection.

Kelly. Well, thank you, Garrett. Good morning, everyone. My name is Kelly Yancey. I work with Garrett in the security engineering and architecture team at Apple. And last year at WWDC 2018, it was my privilege to introduce the new privacy protections in macOS Mojave, broadly characterized-- sorry. Let's get to that. These protections were designed to improve user's transparency over their-- how their data was being accessed and give them control over those accesses. And I'm really excited to be back here today to talk about the improvements that we've made in macOS Catalina.

Now, broadly characterized, their privacy protections require user consent to access hardware that could record the users, such as the camera or microphone, or to access the user's privacy sensitive files or folders, such as photos, mail or messages.

In addition, they also protect the ability to automate other apps, so that the user is in control over how their data is being shared between apps.

I like to start today by looking at the recording capabilities.

Beginning in macOS Mojave, users have to consent before an app can access the camera or microphone. And then macOS Catalina further requires consent to record the contents of your screen or the keys that you type on your keyboard. And this is important because just like we don't want people shoulder surfing, looking over our shoulder to see what we're doing or are typing, we don't want apps to eavesdrop on our contact information, our bank details or passwords and so on, whether that's intentionally or accidentally. So how do we do that? Let's start by looking at screen recording. Here's a simple example of using CGDisplayStream to record the contents of a display in real time. On macOS Catalina, the first time this app runs and this call to create the CGDisplayStream is made that'll return nil, and a dialogue is displayed directing the user to the security and privacy preference pane, where the user can approve the app to record the screen if that's what they want to do. The same is true when reading the contents of other apps windows. For example, here's a function that saves the contents of a window to an image on disk.

Now, notably, the call to CGWindowListCreateImage can return nil, if passed the window ID that does not belong to the calling app, and doesn't belong to the desktop background image or to the menu bar. And I like to emphasize, this is the background image, it doesn't include the icons or names of any files on the desktop.

Again, an authorization dialog, directing the user to approve the app for screen recording, may be displayed. And I say may, because the dialog is only displayed the first time CGWindowListCreateImage or CGDisplayStream fails due to a lack of approval for screen recording. Another topic I'd like to cover that's peripherally related to screen recording is window metadata.

Apps can query metadata about the windows that are on or off screen using the core graphics CGWindowListCopyWindowInfo function. The metadata returned includes the size and position of the window and the unique window identifier, as well as the name and process of identifier of the app that owns the window. However, the window name and sharing state are not available, unless the user has preapproved the app for screen recording. And this is because some apps put sensitive data such as account names or more likely web page URLs in the window's name.

And CGWindowListCopyWindowInfo never triggers an authorization prompt, instead it filters the set of metadata that it returns to the caller. So, if in your app you depend on getting the window name, for example, and you find that the metadata that's being returned doesn't include the window name, you may want to alert the user and direct them to the privacy-- security and privacy preference pane.

So, here's an example of a function that gets the unique window identifiers for the desktop background image for each display. And once again, the background image doesn't include the icons on the desktop.

This function first gets a list of all of the windows on the screen, using the CGWindowListCopyWindowInfo function.

But then, it gets the window level or Z order that core graphics uses for the desktop background image window.

Then it filters that whole window list to just those windows at the desktop background window level. So if you look on the internet, you'll find a lot of code samples filter by the kCG window name which, since the window names may contain privacy sensitive information, would require the app to be preapproved for screen recording. However, by identifying the desktop background windows by their window level rather than by the window name, this works regardless of whether the user has preapproved the app for screen recording. And this is an example of how a small change in your-- the design of your app can make a big difference in the user experience. So that's how macOS Catalina protects the contents of your screen from being recorded without your permission. Apps can freely record the contents of their own windows, the menu bar and the desktop background image.

But the user must use the security and privacy preference pane to preapprove apps to record the entire screen or the contents of windows other than their own.

Now, I'd like to present the other recording capability now protected in macOS Catalina, your keyboard. Most users have an expectation that their keystrokes are only going to the app that they're interacting with, the front most app, and most apps only require a keyboard input when the user is actively using them. And in fact, if your app uses the standard UI components, they handle those keyboard events that are being delivered to your app automatically. Now, some apps want to be able to intercept those events as they're being delivered to their app. And that's fine, they can subclass NSApplication and override the sendEvent method, or as shown here, you can use NSEvent's addLocalMonitorForEvents function. Monitoring all keyboard events, including those for other apps, however, requires user approval.

And here you can see an example of using CGEventTapCreate to invoke a callback for key press and release events.

Now, the first time this code runs, this call, the CGEventTapCreate will fail and return nil. Meanwhile, a dialog is displayed directing the user to the security and privacy preference pane, where the user can approve your app to monitor keyboard events in the background, if they so desire. Now, apps may check the authorization status without triggering the approval prompt, using the IOHIDCheckAccess function with the kIOHIDRequestTypeListenEvent parameter. And apps can request an approval dialog to be displayed without creating an event tab or trying to post an event by using the IOHIDRequestAccess function, again with the same parameter. So in summary, macOS Catalina now requires user consent for apps to record the contents of your screen or the keys that you type on your keyboard.

Now, I'd like to turn your attention to how macOS protects access to your privacy sensitive files. So continuing the approach in Mojave, macOS Catalina offers two broad levels of privacy protection for the user's files and folders. First, user data that apps may generally access such as contacts or photos, and for these, macOS will confirm that the user consents before sharing that data with apps.

But second, there's also user data which-- for which the file system is really just an implementation detail, it's not part of their API. And these are things like mail or messages and Safari browsing history. And these have a high barrier to access because the files are typically only accessed by specialized apps such as disk management or backup utilities.

But first, let's talk about those files and folders that require user consent to access. Now, macOS Mojave introduced user consent requirements to access your contacts, calendars, reminders, or your photos library via the file system. And what that looks like is a prompt like this, when an app tries to access files in one of these categories. Now, this is different than the authorization dialogs that we just saw for screen recording and keyboard event recording, rather than denying the access and displaying an alert to the user, the calling thread is actually blocked, waiting for the user to approve or deny the app access to files in the category.

In macOS Catalina, we complemented these categories with these additional categories for data where the file system is API.

These represent various locations where the users store their documents.

They double click on them in Finder. They select them via Open or Save panels, and so on. The user's desktop and document folders were prime candidates for protection since that's the default location where many users store their files.

And downloads because some apps, including Safari, save downloaded files there by default, also protecting documents stored in iCloud Drive or third-party cloud storage providers or on removable volumes and if you've been around as long as I have, you may be thinking floppy disks. But here I mean any storage that can be physically removed, including USB thumb drives or external disks.

And as I'm sure you photographers out there can attest, some people have their entire lives chronicled on external disks, or on network-attached storage.

So, macOS Catalina is now protecting many of the most common locations where we store our files. Now, user consent is not required for an app to create new documents in any of these protected locations, just to read existing contents, the contents of files that are already there. So, for example, a file transfer app can continue to save new files to the user's downloads folder without triggering a consent prompt. And user privacy protections in macOS Catalina now support the notion of user intent, when-- which is inferred when double clicking on files in Finder, when dragging and dropping from another application or when selecting files in an Open or Save panel.

And when the user performs any of these actions, the file-- performing any of these actions on a file protected location, your app gets access to the file or files that the user selected without the need for a consent prompt. So let's see how Catalina's inference of user intent compares with user consent.

Sorry. So, first of all, user consent is reactive. Access may be granted only after your app tries to read or write a file, whereas user intent is proactive. Access is granted before the app, even tries to read or write the file. And user consent prompts to kind of interrupt the user's workflow, whereas user intent is inferred from standard UI interactions.

In order to minimize those interruptions, user consent applies to an entire class of data, for example, all files on your desktop. Whereas user intent is inferred for just the file or files that the user is interacting with.

Now, that said, the two are not mutually exclusive. So long as your app is accessing files it created or which the user selected, no consent prompts are necessary.

But if your app accesses files in a privacy protected location, other than ones that it created itself or ones that the user has selected, the user will need to approve that access via consent prompt.

Now, one common scenario where an app might need to access a file other than one that the user selected are sidecar files.

For example, to automatically open a subtitle file that's-- with-- of the same name but next to a movie file.

So using the related items support in NSFileCoordinator, it's possible for the inferred permissions for one file to be extended to other files.

To use NSFileCoordinator to open a sidecar file, you need to first declare the extension of the sidecar file in your apps, CFBundleDocumentTypes Info.plist key. And, set the NSIsRelatedItemType to Boolean true.

Then in your code, you subclass NSFilePresenter, set the primaryPresentedItemURL to the file that the user selected. So that's the one that your app already has access to. And the PresentedItemURL to the sidecar file. That's the one that you want to access to.

And note that the sidecar file may have a different extension as the user selected file, but all other path components must be identical.

Finally, you create an NSFileCoordinator referencing the NSFilePresenter instance.

And when you call the NSFileCoordinator's coordinate method, your app gets access to the sidecar file as well for the duration of that block. And that's a quick rundown of how your apps can use NSFileCoordinator to gain access to files with the same name, but a different filename extension as ones that the user has selected without triggering a user consent prompt.

Now, to securely infer user intent, the Open and Save panels are now always hosted out of process. As a result, the class inheritance and view hierarchies have changed, which could affect your app if you have subclass NSOpenPanel or NSSavePanel. And apps can no longer programmatically accept the panels by calling the OK method, the user must do that themselves.

There are also slight changes to the NSOpenSavePanelDelegate methods as well. Apps can no longer rewrite the user selection using this method. And accessing the files that URLs provided to these methods may trigger user consent prompts, because these methods are invoked by the panels while the user is still interacting with the panel, so they haven't selected the file yet. So therefore, your app has not yet been granted access. Now, apps can test whether a given file is readable or writable without triggering consent prompts using these APIs. And, so long as your app only accesses files that the-- that in itself creates or that the user-- that it receives via file open events or drag and drop or Open panel or Save panel selections, your app's permission to access those files is inferred and no user consent prompt is necessary. However, if a consent prompt is required, all of the new protected file system locations support purpose strings. And purpose strings can be specified in your Info.plist to explain the context of the access when a consent prompt is displayed.

And while purpose strings for these categories are optional, if your app access is one of these protected locations, intentionally, a purpose string for that location is highly recommended so that the user understands why your app is accessing their documents. Now, if you find in your testing your app is triggering consent prompts that you don't expect, you can click the Don't Allow button and go to the console app and look for the resulting Sandbox violation, that'll tell you the file that your app was trying to access and the backtrace that caused to require the consent prompt. So that's how macOS Catalina is protecting user's documents and how the standard UI and how it's using standard UI interactions to infer which documents they expect apps to access.

So let's look at how macOS protects user data that's managed by the system and how your apps can request access to that data if necessary.

Here, we see the categories of data protected starting in macOS Mojave. Now, some software such as disk management or backup software work with all files regardless of their content. And those software-- those apps can use the same APIs that we just saw a minute ago to determine whether a given file is readable or writable. And then depending on what's appropriate for the app, they could skip inaccessible pass or they could alert the user and direct them to approve the app in the security and privacy preference pane to have full functionality. And here's where they would approve that for Full Disk Access. And while we're here, I'd like to talk about one of the enhancements that we've made in macOS Catalina to how apps are approved for Full Disk Access, while users can still manually add apps to the list using the plus button here.

One piece of feedback that we've gotten from developers is that it can be awkward for users to locate their app's privileged helpers. So, now in macOS Catalina, executables that are denied access to files due to a lack of Full Disk Access approval are now prepopulated unchecked.

Here, we see one such helper identified by its executable name. If that helper were embedded in a bundle, the display name in icon specifying the bundles Info.plist would be displayed instead.

So, again, this data is accessible for apps that have been preapproved for Full Disk Access, apps can test for authorization using FileManager or POSIX level APIs, and if necessary, can guide the user to the security and privacy preference pane, where the user can then approve the app if that's what they want. Now, in Catalina, the universe of data that requires preapproval for Full Disk Access has been expanded to include trash.

Now, a lot of people think of files as being gone when they move them to their trash. So the last thing they would expect is for something to go digging through their trash files. That's terrifying, at this size.

As with these other categories, trash may contain lots of privacy sensitive data. However, unlike these other categories, trash is file centric and does have API for manipulating those files. APIs like these, which move files into the user's trash.

Now, I'd like to drill down on the FileManager trash item API a little. It takes a URL of the file to move to the trash as it's argument. Now, the caller needs to already have access to that file, you can't move files to the trash that you're-- you don't have access to yourself.

But when successful, it populates the out resulting URL parameter, with an NSURL for the file at its new location in the user's trash.

And it still has access to that URL. To make sense, it had access to the file before it moved it. It still has access to the file after it moved it. And this allows you to use FileManager APIs, for example, to move the file back out of the trash. So in summary, while apps require Full Disk Access to enumerate the files in the trash or to see those files contents, no authorization is required to move files into the trash or to access files that they had previously put in the trash.

Finally, I like to talk briefly about automation.

macOS Mojave introduced consent requirements for automation of the system or of other apps. And this is important to prevent malware from abusing apps that you've trusted with your data.

So, first, there's synthetic events. And synthetic input events are typically used by accessibility software in providing aid for keyboard or mouse input. But because user consent dialogs, user intent inference or various other security prompts all rely on user input, it's important that synthetic input events are only allowed from apps that the user has installed for the purpose of acting as their proxy. Here's a sample code-- Here's an example of code that simulates a key press and key release. The first time this code runs and tries to post these events as if they were actually typed by the user, the events are discarded. And a dialog like this one is displayed alerting the user that they will need to go to the security and privacy preference pane to authorize the app for accessibility features.

Now, earlier, we looked at this sample code for listening to keyboard events. If I change the listenOnly parameter to defaultTap, like that, CGEventTapCreate now creates a modifying event tab, where the callback can alter the event stream. And this means now your app has a way to influence what events are delivered to the rest of the system, where a listen-only event requires authorization for input monitoring, a modifying event app requires authorization for accessibility features. Now, apps can test whether the user has approved the app to synthesize local-- synthesize input events using the IOHIDCheckAccess function. And this is the same API for checking authorization for keyboard input monitoring. But, here you can see that we're passing the kIOHIDRequestTypePostEvent instead. So, that was automation via synthetic events. Now, let's talk about automating apps via Apple Events.

So, the user must consent before one app can use AppleScript or raw Apple Events to control the actions of another app. These consent prompts make it clear, which apps are acting under the influence of which other apps and give the user control over that automation. Now, there are exceptions for Apple Events that don't give the sending process access to privacy sensitive data. Many of these events are exposed via NSWorkspace APIs.

The AEDeterminePermissionToAutomate Target function can be used to test whether authorization would be required to send Apple Events to a target application. And here's an example, testing whether the caller can send any Apple event to Keynote. And by passing Boolean true for the askUserIfNeeded parameter, you could ask that a approval prompt is triggered if necessary.

But I will point out that if a prompt is displayed, the calling thread is blocked waiting for the user's interaction, so you wouldn't want to call this on your app's main thread.

Now, this API is pretty low level, returning an OSStatus code indicating whether the caller is permitted to send the Apple event to the target or not, whether trying to send the Apple event would result in a prompt confirming the user's consent, or whether the target is not running at the moment and that trying to send the Apple even would cause it to launch, or whether some error occurred. So that was a quick summary of how macOS captures user consent before allowing apps to automate other apps, and how your apps can determine whether consent was given and adjust accordingly.

So, now, in macOS Catalina, user consent is required to record your screen or keyboard, that's an addition to the existing protections for camera and microphone. And now, a number of common location-- common document locations are also protected such as user's desktop documents downloads, their iCloud Drive or third-party storage, removable network volumes and, of course, trash. Now, the Privacy Preferences Policy Control MDM payload has also been extended with services for the new protected resources in macOS Catalina. And, I'd like to point out that during development, you may want to trigger-- be able to retrigger prompts while you're testing your app behavior. And you can use these same service names that you see on the left side, with a tccutil command line tool to reset the prompting status for the respective protected resources.

So, earlier, we heard from Garrett about the enhancements in Gatekeeper, and we just discussed some of the improvements in the user privacy protections in macOS Catalina. I'd like to recap by saying, remember to sign and notarize all of the software that you distribute. And, don't modify those bundles once signed. If you do need to modify the bundles, be sure that you just transform them into another bundle that is also signed. And, for user privacy protections, try to leverage standard UI as much as possible. Be sure to handle errors and APIs that may return, if the user-- sorry, handle any errors, APIs may return if the user declines consent. And remember that once users authorize your app to access their personal data, it's-- the responsibility to protect their privacy passes to you. So handle user's data with care.

Thank you very much. I hope you enjoy the rest of the week here at WWDC. There's a security lab immediately afterwards if you have any questions about these or any other of the privacy or security protections in macOS. Thank you very much. [ Applause ]