August 22, 2018, 10:24am EDT
Apple is adding more privacy protections in macOS 10.14 Mojave. Mac applications must request permission before accessing data like your photos, emails, webcam, microphone, calendars, and contacts. If an app tries accessing protected resources without permission, it may crash.
What You Need to Know
macOS Mojave provides additional protection for your private data. In the past, apps running on your Mac could access much of this data without asking you for permission. Now, to better protect against malware or sneaky apps viewing your data without your permission, apps must request access to more resources.
This permission system is similar to the one on Apple’s iPhones and iPads. However, it’s a bit clunkier because Apple designed the mobile iOS operating system for permissions from day one. On the macOS side, there’s a universe of older Mac applications that don’t understand permissions. These apps assume they have access to these resources, which can cause problems.
Most of the time, you won’t even notice this new permission system, and you won’t need to think about it. Any problems should become rarer as app developers update their applications to work properly with macOS Mojave, too. But you may have some teething issues while running older applications.
This works differently from standard file and folder permissions, which still work in the traditional way. For example, if you’re running an application from your user account, it can only access files to which your user account has access. But, with these additional permissions, that app won’t have access to your photo library unless you explicitly allow it—even though your user account has access to your photo library. It’s an additional, more granular layer of restrictions.
What Data Do Apps Have to Ask For?
Apps must prompt you for permission before accessing location services, contacts, calendars, reminders, and your photo libraries. They must also get your permission before accessing your camera, microphone, or your Mac’s automation features. Importantly, the app’s developer has to declare these capabilities as part of the app. In other words, if an app’s developer hasn’t designed the app to ask for photo permission, you can’t give the app access to your photo library.
Apps also don’t typically have access to special types of application data, including anything in your Mail app, messages, Safari browsing history, Safari cookies, Time Machine backups, and iTunes backups, without your permission. These types of special application data are included in the “Application Data” category in your Mac’s settings. You can give any app access to this special application data. There’s no way for app developers to request access to it.
How to Give Apps Access to Data
Apps are supposed to prompt you when they want to access protected private information, such as your photos or contacts. You might see prompt messages when an app wants to access this data. Just agree to the prompt to give the app access, or click “Don’t Allow” to block it.
You can also configure these restrictions from your Mac’s System Preferences window. In fact, you might have to use this window if the app doesn’t prompt for access. You can also head here to revoke permission you’ve given, or allow permission you’ve previously denied.
To find these settings, click Apple menu > System Preferences > Security & Privacy > Privacy.
Go through the categories here to see which installed apps are capable of accessing which types of content. For example, to see which apps can access your photos, click the “Photos” category.
You can’t give an app access to this data if it doesn’t ask for it. If you want to provide an installed app access to your photo library but it doesn’t appear in this list and doesn’t ask for access to the photo library in the app itself, there’s no way to add it. The developer has to declare that capability in the app and release an update.
However, you can always export a photo from your library and save it in an unprotected folder, like your Documents or Desktop folders, and then open it in another application.
To choose which apps can access miscellaneous other app data, click the “Application Data” category. First, click the lock icon and type your password. You can then click the “+” button to add any installed app in this list, giving it access to application data like your mail, messages, history, cookies, and backups.
There’s no way for apps to request access to this data or declare they can handle it. You have to go to this pane and add them to the list manually if they need this access. For example, you might need to come here and give system tools access to your application data if they need to work with these protected folders.
What to Do If Apps Crash or Can’t See Files
Two problems might occur if an app doesn’t have access to a resource and you try accessing it. The app might simply crash, as macOS Mojave terminates it for trying to do something that isn’t allowed.
In other cases, macOS Mojave will just not let the app see the data. For example, you may try opening a protected folder only to see its contents as blank and empty.
If the app crashes or can’t access data, but doesn’t prompt for access, go into your Security & Privacy pane and give the app access to the category of data, if possible.
If you need to access a file in a protected location, copy it to a not-protected location. For example, if you have an email attachment you want to open, go into Mail and save the attachment to a folder like your Documents or Desktop folders, which aren’t protected. If you want to access a photo in your photos library, export a copy of the photo to your Documents or Desktop.
If the app needs to access a type of data, but you can’t give it access to that data, contact the app’s developer and let the developer know the problem. This is likely an issue the app developer needs to fix. Problems should become less common as developers update their apps for Mojave.
Thanks to The Eclectic Light Company for bringing our attention to Mojave’s privacy protections and what Mac users will need to know about it.
Yesterday, I looked at how I am dealing with Mojave’s new privacy protection in my apps. In previous discussions here, we have established that the situation with respect to command tools and shell scripts is unclear and uncharted. This article attempts to explain how my command tools will cope.
Command tools are a bigger problem for Mojave’s privacy protection, because there are so many of them, both in macOS and running on it, because they generally conform to Unix conventions and expect to be able to access wherever permissions allow, and because their structure is far simpler. Yes, you can give them embedded property lists containing magic strings, but that’s not how they usually come. By definition, they also lack a GUI, although in some circumstances they can invoke dialogs provided by macOS.
My recent command tool cmpxat , which compares two files with respect to their extended attributes, could quite reasonably be applied to any two files anywhere in a Mac’s storage, within the constraints of permissions, so is a good example of a tool which needs to operate within Mojave’s privacy protected zones.
When I first ran cmpxat on two protected files, I was surprised at the result. At first, Terminal displayed a -1 as if the command was about to return an error, then came the new user consent dialog.
Note how this doesn’t give the name of the command being run, but the environment in which it is running, the Terminal app. When I clicked on OK to authorise it, the command completed normally in Terminal.
I then found, to my surprise, that macOS had automatically added the Terminal app to the list of apps authorised Full Disk Access, in the Privacy settings.
What happened in the log is also puzzling. Although cmpxat is now able to obtain access to protected items, this can throw sandbox errors in which the request appears to be denied:
00.817128+0100 Error com.apple.sandbox.reportingSandbox: cmpxat(556) System Policy: deny(1) file-read-xattr /Users/hoakley/Library/Mail/V6/D977E517-3CF5-415F-9A9C-2F2FDD63A994/INBOX.mbox/D7BCE9D7-25E3-44DF-9368-C4ED56747768/Data/Attachments/5/2/092915 APP Mac UK-Ireland v2.2.pdf
Violation: System Policy: deny(1) file-read-xattr /Users/hoakley/Library/Mail/V6/D977E517-3CF5-415F-9A9C-2F2FDD63A994/INBOX.mbox/D7BCE9D7-25E3-44DF-9368-C4ED56747768/Data/Attachments/5/2/092915 APP Mac UK-Ireland v2.2.pdf
Process: cmpxat 
But despite that error, that command completed correctly and returned the expected result.
The com.apple.TCC subsystem and tccd seldom get involved. When they do, they appear most concerned with establishing an ‘Attribution Chain’ to the calling process, which in this case is held to be the app Terminal.
The outcome may be to silently add the Terminal app to another one of the items in the Privacy list, accommodating that command and similar access in the future.
As far as I can tell at present, what happens when a user or script tries to run a command tool on one or more protected items is that TCC establishes its Attribution Chain back to an app which it recognises, like Terminal. It then behaves as if it is that app which is accessing the protected items. If that involves displaying a user consent dialog, then that occurs, giving the app as the caller.
This works well for tools called through Terminal, as it doesn’t suffer the constraints which are applied to third-party apps, even when running third-party tools. Neither the tool nor Terminal appears to be at any risk of being forced to quit, although execution of the tool will be delayed until the user has given consent in any resulting dialog.
I have two areas of concern, though.
First, once the user has consented to one tool being run in Terminal on a class of protected data, consent will not be sought again for other tools run in the same app environment. For those who only occasionally run command tools, best practice may be to uncheck Terminal in the various lists in Privacy settings, lest other command tools be given similar access without obtaining further consent.
Second, this is fine for obvious Attribution Chains going back to Terminal or the like. I presume that, if a third-party app were to call its own command tool(s), TCC would expect that app to conform to the same rules as other third-party apps, as I have described in the previous article. If you develop an app which relies on non-Apple command tools, you should be extremely careful that this doesn’t lock your tools from accessing protected items, as the user may be unable to do anything to restore that access.
I don’t know how the Attribution Chain works when there is no app at its head, for example when a command tool or service is called from a LaunchAgent or LaunchDaemon. This is again something which requires very careful testing and exploration: it would be extremely frustrating if running a backup tool at 0300 on Sunday morning invoked a consent dialog which wouldn’t be seen until 0800 on the Monday morning, for example.
The Attribution Chain is also of great significance to malware, which might use command tools and scripts to try to harvest personal data for a C&C server, for instance. The robustness of TCC and its privacy protection will determine how easily it can be exploited by such malware – which is surely one of the major justifications for all these new systems in Mojave.
Some of the most intractable problems in Mojave are those arising from its new privacy protection. The Privacy pane in Security & Privacy and the command tool tccutil intentionally give users, sysadmins and developers almost no help. Most of the lists in the Privacy pane aren’t directly controlled by the user, and all tccutil seems able to do is wipe the contents of those lists. When you have a problem, you’re stuffed.
Until now, the only steps you can take beyond those involve reading the entitlements and other settings for the app, and wading through the log. Because of the way that the protection works, you can’t tell how it has handled an app or command tool’s request to access protected data or services unless you browse through thousands of entries in the log. Even using Consolation, that is far from easy.
I have now extended my free app Taccy, which already helps you examine entitlements and settings in an app, to provide customised access to the unified log which should make troubleshooting privacy control a great deal easier. If you’re familiar with Cirrus, which does the same for iCloud, then you’ll already be familiar with this new feature.
Taccy’s new log browser window gives instant access to selected log entries from the main subsystems involved in privacy protection: TCC, LaunchServices, securityd , and selected entries from tccd (the service at the heart of privacy protection) and sandboxd . The best way to explain this is to demonstrate its use.
I opened my app xattred when the system clock reached 17:04:00, then about 16 seconds later, had navigated it to open a file in my protected Calendars folder. This all worked fine, as xattred has the correct settings and info strings to ensure that TCC should let it do that.
I then opened the new version of Taccy, opened a log window, ensured the time period set went from 17:03:57 to 17:04:30, and clicked on its Get log button.
I show you here just a short excerpt from the log extract in Taccy, which shows what happened when I tried to access the Calendars folder. Although I have abbreviated some of the entries (marked with square brackets ), these are consecutive entries and haven’t been edited to remove intervening ‘noise’.
Accessing the Calendars folder is, for a hardened app, considered to be a request to the sandbox which it runs in, so the first entries show that being passed to TCC:
16.287 sandbox request approval
16.287 sandbox TCCAccessRequest() IPC
16.287 TCC Sending 0/7 synchronous to com.apple.tccd: request contents = “service”  “kTCCServiceCalendar”  “function”  “TCCAccessRequest” 
The TCC service daemon asks for a SecTrust evaluation, and handles the request:
16.287 tccd SecTrustEvaluateIfNecessary
16.287 TCC tccd(501): handling request 
16.287 TCC PID is checking access for target PID
16.288 TCC Created SecCodeRef 0x7fae04a4edc0 for PID.
16.288 tccd SecTrustEvaluateIfNecessary
16.288 tccd SecTrustEvaluateIfNecessary
securityd checks the certificate:
16.289 securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (tccd/0#-1 LF=0)
16.289 securityd cert: AnchorTrusted =(leaf)[force]> 0
16.290 tccd SecTrustEvaluateIfNecessary
TCC confirms that this is valid static code, then handles the request to access the Calendars folder:
16.291 TCC matchesCodeRequirementData: SecStaticCodeCheckValidity()  from co.eclecticlight.xattred ; result: 0
16.291 TCC Handling access request to kTCCServiceCalendar, from co.eclecticlight.xattred 
16.291 securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (tccd/0#-1 LF=0)
16.291 securityd cert: AnchorTrusted =(leaf)[force]> 0
Finally, TCC grants the request, and tells the sandbox it can go ahead:
16.291 TCC Received synchronous reply  “result” : true
16.292 sandbox kTCCServiceCalendar granted by TCC for xattred
Note that in Taccy’s log window, each source of entries appears in a contrasting colour, for example with TCC shown in red. With the click of a checkbox, you can select which sources will be shown. If you’ve got lots of entries from other processes accessing TCC at the same time, you can use the standard Find feature to locate those entries which refer to the app that you’re assessing.
Among the crucially important log entries you’ll see when you use this are those which reveal TCC’s Attribution Chain, for example
16.273 TCC AttributionChain: ACC:
which shows that a request from sandboxd is being attributed by TCC to xattred, whose entitlements will determine the outcome. Attribution Chains are vital information when trying to discover why a command tool isn’t being given access to protected data, as it is normally the head of that chain, such as Terminal.app, whose privacy settings determine access for commands being run from that.
This new feature should make Taccy a much more versatile tool for anyone wanting to investigate problems with privacy protection in Mojave, and for those wanting to investigate TCC further. It is now available from here: taccy10b7
and from Downloads above.
macOS Mojave’s privacy controls are found in the Privacy tab of the Security & Privacy pane in System Preferences, and in one command tool, tccutil .
There are three different sets of behaviours, depending on the type of protection.
- Location Services – your location
- Contacts – the contents of
Calendars – the contents of
You cannot add items to these manually. If you use an app which needs access to any of them, it should prompt you with a dialog inviting your consent. Only if you give your consent will that app be added to that list. Once added, you can disable its access to that private data by unchecking the checkbox next to it. You cannot remove the item from that list except by using tccutil .
- Accessibility – includes access to Automator’s Watch Me Do recording and playback of user actions
- Full Disk Access – access to the whole disk, within the limits of normal permissions.
Apps cannot normally add themselves to these lists, although Apple’s apps can add items to Accessibility but not enable them. You can add apps, command tools and other items as you wish, to grant access to those protection categories. To add an app, click on the + tool at the foot of the list, select the app in the dialog, and click Open.
Adding items embedded within an app is best done using drag and drop: in a Finder window, locate the item, if necessary using Command-Shift-. to show hidden items, or by opening an app’s bundle using the Finder’s contextual menu, and drag and drop it into the list.
Once added, you can temporarily disable its access to that private data by unchecking the checkbox next to it. You can also remove that item from the list by selecting it within the list and clicking on the – tool at its foot. Once removed, you can always add that item back in the normal way, as this is not a permanent ban.
In addition to the Contacts, Calendars, Reminders, and Photos data controlled by specific classes and listed above, Full Disk Access also gives access to:
Mail – the contents of
Messages – the contents of
Safari browsing history – the contents of
Cookies – the contents of
/Library/Suggestions, most of which are new to Mojave.
- Automation – the ability of one app to control the behaviour of another using AppleEvents, AppleScript, and similar.
This lists pairs of items: the first is the app which controls the second. You cannot add pairs to this manually. If you use an app which needs to control another app, it should prompt you with a dialog inviting your consent. Only if you give your consent will that pair be added to that list. Once added, you can disable control over specific apps by unchecking the checkbox next to the controlled app. You cannot remove the pair from that list except by using tccutil .
Analytics and Advertising cover other aspects of privacy protection.
tccutil can only clear apps currently given access to certain classes of protected data. It cannot be used to add or enable apps in those classes. It is used in one of two forms:
tccutil reset service
clears all current settings for the named service, or
tccutil reset service bundleID
clears the bundle identified by bundleID, e.g. co.eclecticlight.myApp, from the named service.
Named services currently include: Accessibility AddressBook AppleEvents (for Automation) Calendar Camera Microphone Photos Reminders All .
Mojave’s new privacy protection is delivered by the Transparency Consent and Control (TCC) system, which is not new to macOS 10.14 by any means. Look back in Sierra’s logs and you’ll find a few of its messages there, but it has a much more limited role so there is little to see. It started to become more prominent in High Sierra, and is now one of the more chatty subsystems in the log. This article explores some of its basic behaviours in Mojave, illustrated with log extracts.
TCC’s background service is tccd , whose only documented control is in tccutil , which merely clears existing settings from lists in the Privacy tab of the Security & Privacy pane. Its front end is that Privacy tab. In the unified log, TCC’s entries come from the subsystem com.apple.TCC .
There are three well-known folders which contain TCC’s data:
- /System/Library/Sandbox contains TCC_Compatibility.bundle, which contains an AllowApplications property list in the overall path /System/Library/Sandbox/TCC_Compatibility.bundle/Contents/Resources/AllowApplications.plist. This is a signed bundle, currently at version 14.0, and doesn’t appear to have been updated since the release of Mojave.
- /Library/Application Support/com.apple.TCC contains the system database TCC.db, and may contain two overrides property lists named MDMOverrides.plist and SiteOverrides.plist. Those property lists appear to be installed only when that Mac is being managed by MDM.
/Library/Application Support/com.apple.TCC contains the user-specific database TCC.db. It doesn’t appear to be capable of containing user-specific overrides, though.
TCC doesn’t appear to start until over 5.5 seconds after startup in Mojave, and then normally in response to a synchronous request from WindowServer for Installer Progress. Its startup is summarised in the log entries shown below.
The first steps are to load overrides from MDMOverrides.plist and SiteOverrides.plist, if those files exist. On non-managed Macs, they shouldn’t, but AllowApplications.plist should, and will then be loaded. Its contents aren’t apparently added to the database in any persistent way, and this property list is loaded each time that Mac starts up.
AllowApplications.plist currently consists of an array of dictionaries under the key PostEvent, which is under the key Services. These are code requirement specifications for just over 30 apps, including different versions of Adobe Dreamweaver. It is not clear whether this is a whitelist or blacklist, though.
As each of those dictionaries is added, TCC writes an entry in the log as a PostEvent, and gives the code requirement from the property list.
Once all the overrides are loaded, TCC reports that its service is starting as com.apple.tccd.system with the root user ID. It then purges expired access entries from the database, and gets on with processing requests.
Overrides are first loaded around 5.5 seconds after startup, and are loaded again after a total of 17 seconds, about one second after the user has logged in. The first load thus applies to system usage, and the second for the logged-in user.
Many requests then follow to TCC. These show a similar pattern, which I will try to interpret. The example shown above is from the Login Window, and is an access request. The first log entry shows TCC putting a synchronous request to tccd . It is first displayed in its original form as a dictionary with five entries, then tccd repeats the request as received.
TCC converts from actual user IDs as given, to effective user IDs (euid), then builds details of the process making the request, in this case WindowServer. The next entry shows the Attribution Chain which TCC uses: although the request has come from WindowServer, which is given in the REQ field, it is actually loginwindow which is at the head of the chain to accept responsibility, given in the ACC field.
Subsequent entries step through TCC’s internal processes, and culminate in receiving a synchronous reply, which is again a dictionary, and gives authorisation with the boolean value of true .
Follow com.apple.TCC in the log and you will see hundreds, thousands of similar exchanges taking place. Because that was early after startup, it is perhaps less representative of the most common pattern, which is shown in the excerpt above. This contains:
- The request to tccd in the form of a dictionary;
- tccd handling that request;
- Generation of euids;
- Construction of details of the accessing process;
- Construction of the Attribution Chain, giving the REQuesting process and in the ACC field the head of the chain;
- The Entitlement Check for the head of the Attribution Chain;
- Authorisation by tccd ;
- A synchronous reply, again in a dictionary returning the authorisation result of true .
One unanswered question is how TCC data will be updated by Apple. In its Support Note detailing Mojave’s background updates (a valuable resource in itself), Apple includes “TCC Configuration Data” in its list of silent background updates, which “improves compatibility of specified software with macOS security features”.
The only repository of TCC data which appears intended to be updatable at present is /System/Library/Sandbox/TCC_Compatibility.bundle. I am watching this like a hawk, and may need to add it to the bundles covered by LockRattler.
If you’re suffering problems with TCC, in particular when you have an app which should be generating a consent dialog but doesn’t, as well as checking that app’s entitlements and usage strings using Taccy, try inspecting the log with the single predicate ‘subsystem == “com.apple.TCC”‘ and looking for an exchange involving that app’s ID. It is easy to do that in Consolation 3, as you can make the app’s ID a filter, rather than part of the predicate. Once you have located the relevant log entries, remove that filter and browse all the messages from TCC around that time.
If you’re struggling to work out what to add to your Full Disk Access list to get a command to work, then you should be successful when you add the item listed in the ACC field of the Attribution Chain shown by TCC.
Carl Ashley’s blog is an excellent resource: his take on log entries is slightly different, and is here. He is particularly focussed on management using MDM configuration profile payloads, and has an excellent summary here.
Rich Trouton’s Der Flounder blog is another valuable source of information, for example this article aimed again mainly at sysadmins using MDM.
Setting up a new computer is hard enough, but if you’re privacy minded, things are even more complicated. This is especially the case with a Mac, which keeps all kinds of stuff behind the scenes. Whether you’re setting up a new system or installing a new version of OS X, now’s a good time to check your privacy settings.
We all need to protect our private data . But when you’re working with sensitive files, pictures, and your passwords , you want to ensure other people can’t easily get to it. Beyond that, with a Mac, even simple things like your text messages can pop up in someone else’s face if you’re not careful. For some of us, this can feel like a huge privacy issue, but thankfully OS X has tons of settings you can tweak to lock down your data, search results, and more.
From Saucy Pics to Passwords: How to Share Sensitive Information Over the Internet
Raise your hand if you’ve shared a username and password with someone over IM? Ever share a…
Audit OS X’s System Settings
By default, OS X is all about ease of use. This is great, except that it means your private data is general in the open, sitting around for anyone (or any app) to find. Much of the default behavior in OS X is meant to make things easier for you, but it also means that if someone sits down at your computer they can accidentally come across a ton of stuff you might not want them to. Here are a few general settings worth tweaking:
- Tweak your privacy system preferences: OS X has a built-in privacy tool that’s worth customizing.. Head to System Preferences > Security & Privacy and select the Privacy tab. Here, you can set which applications have access to your location data, iCloud data, and what can access deep system stuff (this is listed under Accessibility, but mostly includes apps like application launchers and text expansion programs). You can disable app access in bulk here or on an application-by-application basis.
- Turn on FileVault: OS X comes with built-in encryption software called FileVault . When you turn it on, you’ll need a login password or recovery key to see any data on your computer. Head to System Preferences > Security & Privacy and select the FileVault tab. Turn it on and it’ll encrypt your whole drive. This password protects everything, which makes it a lot harder for prying eyes to access your data without your password. It also means you need your password at all time, so don’t lose it!
- Don’t use Keychain: Keychain is Apple’s built-in password system. You have to use it for your login, but don’t use it for your browser data. With just your login password, someone can access all your other passwords, network drives, encrypted files, app passwords, and more stored on your computer. Instead, use a password manager like LastPass or 1Password that requires a master password (beyond your login password) to use.
- Manage your iCloud settings: iCloud is one of the big selling points with OS X is its integration with iOS. iCloud syncs all your photos, files, and everything else across your devices. If you’re on a shared computer, you might want to disable iCloud entirely. Just hop into System Preferences > iCloud and click the “Sign Out” button. It’ll stop syncing everything (which isn’t as convenient), but at least your data won’t be so easily accessible. That said, if you still really want to use iCloud, at least make sure you have two-factor authentication turned on .
- Disable iMessage and Facetime: “Continuity” is a big selling point for Apple. From your Mac, you can send and receive calls and texts that are synced with your iPhone. One potential problem comes when someone else is using your computer (or peeking over your shoulder) and you receive a text message you don’t want them to see. On top of seeing the notification with the message, they can also access entire conversations in Messages. If this is unsettling to you, you’ll want to disable Messages. Open up Messages, select Message > Preferences and sign out of your Apple ID. You can do the same with Facetime for phone calls.
- Disable Spotlight Web Search: In order for Spotlight to work, it needs to send your search data to Google, Apple, and Bing (whichever you’re using at the time.) That’s okay, but any time you search for something using Spotlight, Apple collects that data, too. . While Apple claims this is anonymized, it still feels a bit creepy.. To turn it off, head to System Preferences > Spotlight > Search Results and uncheck the boxes for Spotlight Suggestions and Bing Web Searches. If you still want the power of Spotlight without the creepiness, we recommend Alfred .
- Hide files from Spotlight: Speaking of Spotlight, you’ll also want to customize where it can search for files. If someone is sitting at your computer, they can tap Command+Space to search for any file on your computer (and search inside files as well). This is awesome when you’re looking for something yourself, but also makes it pretty easy for anyone snooping on you. Luckily, you can customize how this works. Head to System Preferences > Spotlight. Here, you can uncheck any boxes for search results you don’t want Spotlight to show. Spotlight will still index those files, but they won’t show in search results. You can also click the Privacy tab and add any folders that you don’t want Spotlight to index. This way, they won’t show up in search results at all.
Once all of those settings are tweaked, OS X is pretty locked down. . You’ll lose some of the functionality that makes OS X convenient, but at least you won’t just be handing private data over to anyone (or any app) who sits down at your computer.
New security features in macOS Mojave
Posted on November 9th, 2018 by Kirk McElhearn
macOS Mojave doesn’t have a lot of visible new features, aside from the new dark mode, but under the hood there are plenty of changes to make the operating system faster, more stable, and more secure. In this article, I’m going to discuss some of the new security features that make Mojave easier to use safer and securely.
As in iOS 12 – read this article about the new security features in Apple’s mobile operating system – macOS Mojave brings a number of new features around passwords that will help make your computing more secure. Together with the keychain, which stores your passwords and which can sync them with your other Apple devices using iCloud Keychain, Safari now suggests and stores strong passwords when you create an account on a website.
If you have had a tendency to reuse passwords in the past – this isn’t a good idea – you can check Safari’s preferences. Click the Passwords icon in the toolbar and you’ll see a yellow alert icon where you’ve used the same password more than once.
Be aware that these alerts don’t always indicate a problem. You may have a password stored for signup.website.com, login.website.com, and website.com because of the way you have had to navigate certain sites. If that’s the case, don’t worry about the alerts.
If you use two-factor authentication on websites, Safari will now automatically insert the codes you receive by SMS into the appropriate fields, as it can do on iOS 12. This works with apps that have been updated to support the feature.
As we discussed in this article, you’ll be seeing a lot of dialogs asking for your permission. While not new, these alerts are now displayed for more situations when software wants to control your computer in some way. You’ll also get specific alerts when an app wants to access the camera or microphone as has been the case in iOS for many years.
In addition, the T2 chip in the new MacBook Air and the MacBook Pro with touch bar disables the microphone on the MacBook Air when its lid is closed. This chip is also in the iMac Pro and the recently updated Mac mini, and is used for other security features such as biometrics (Touch ID).
Safari now limits how websites can fingerprint and track your activity. Fingerprinting is when a website creates a profile about you which is generally shared with advertisers. Safari’s Intelligent Tracking Protection, also included in iOS 12, prevents a lot of this, limiting the ability of advertisers to display targeted ads when you visit websites. Safari has also enhanced its tracking protection so websites and cookies can’t follow you around as you surf the web, especially when they come along with like buttons, share buttons and comment forms.
These are the most obvious new security and privacy features in macOS Mojave. There are others under the hood that ensure that the apps you use are from legitimate developers, and Apple has planted the seeds of an even more reinforced approach to validating apps that may become obligatory on the future. (They call this new review process “notarization.”)
If you haven’t updated to macOS Mojave and your Mac is compatible, you should do so now. These new security features make your computing safer.
November 2, 2018
By Jeff Johnson (Developer of StopTheMadness and Underpass)
This is a follow-up to my earlier blog post Another hole in Mojave privacy protection. Three days ago macOS 10.14.1 was released, the first software update to Mojave. Apple published a support document about the security content of macOS 10.14.1 on the same day. As of today, the support document does not mention the privacy protection bypass that I discovered and alluded to in my blog post. Nonetheless, macOS 10.14.1 does appear to fix the main issue, although there remain other avenues for bypassing Mojave’s privacy protections under certain conditions. I’ll discuss everything I know here.
The privacy protection bypass that I discovered is quite simple. It’s obvious that Apple exempted some of its own code from Mojave’s privacy protections; for example, you’re able to navigate protected folders in Finder without triggering permission dialogs. The key to finding a bypass, therefore, is to think of something that Apple forgot. It helps if you have many years of experience with Macs, as I do, and know where the bodies are buried, so to speak. The body in this case was Automator. Or more accurately, /usr/bin/automator . You can use /usr/bin/automator to run an Automator workflow from the command line. You can also use it to run an Automator workflow from a Cocoa app, as follows:
Only a non-sandboxed app is allowed to do this, but Mojave privacy protections are supposed to apply regardless of sandboxing. Now we just need to produce a “maliciously crafted” Automator workflow. This is trivial:
- Create a new workflow in Automator
- Get Specified Finder Items
The Desktop is not protected by Mojave, and it’s accessible to a non-sandboxed app, so if this workflow works, then the Contacts protection is completely bypassed. On macOS 10.14.0 and earlier, it does work. A newly downloaded and opened app with no special permissions is able to run the workflow successfully without triggering any permission dialog. Game over. On macOS 10.14.1, in contrast, running the workflow triggers a permission dialog for the app, as expected. Thus, as far as I can tell, this particular hole has been filled.
Speaking of command-line tools, another interesting one on Mojave is /usr/bin/tccutil . You can use this tool to reset the privacy permissions for a single app, for a whole service, or nuke everything from orbit. After reset, the permissions that were already granted or declined by clicking dialogs are revoked, and a new dialog will be presented the next time an app needs permission. It turns out that you can also call /usr/bin/tccutil from a Cocoa app using NSTask , as above. An app can reset its own permissions, and this still works on macOS 10.14.1.
A malicious app could exploit the ability to reset privacy permissions by continually presenting permission dialogs to a user until the user loses patience and gives in, granting permission. In other words, the app tries to access a protected resource, Mojave presents a dialog, the user declines, the app checks whether it has access to the resource, and if not, reset the privacy database, try again, as many times as necessary. (Note also that an app can easily disable the Quit menu item, preventing a user from quitting an app to stop the stream of dialogs.
Another possible way to bypass Mojave privacy protections is to “piggyback” on another app. Even if a malicious app is unable to obtain special permission itself, the app can use another app that has already been granted permission, such as Terminal app. Suppose for example that the user has granted Terminal permission to access
/Library/Application Support/AddressBook . Then a maliciously crafted app can make Terminal run a shell script to do the dirty work for it:
This still works on macOS 10.14.1, though of course it all depends on the user having already granted permission to Terminal.
I’ll repeat the message from my previous blog post: Don’t panic. Mojave privacy protection is a new feature in macOS 10.14. Any weakness in the privacy protection is simply a flaw in the new feature. You’re as safe on Mojave as you were on High Sierra, which did not have this feature at all. You just might not be safer on Mojave than you were on High Sierra.
- macOS Mojave (10.14)
- Jul 8, 2018
But it requires SIP to be disabled permanently.
My feeling right now is that Apple are putting in so many restrictions that many people will just disable SIP and that rather destroys the point of SIP.
- Jul 9, 2018
This thread is for posting the good, the bad, and the ugly when it comes to app compatibility with macOS Mojave DB 1. Make sure to update the first page, instead of making individual posts. This is a wiki post. Please keep the apps alphabetized.
Apps that work but are having problems
Agenda (funky UI rulers cut off first couple of columns of notes) (Beta 2 seems to fix)
Airmail 3 (white background over account names for some reason)
Arq Backup (5.12.1) – must manually add “Arq Agent” to “Application Data” category under privacy settings for Arq to be able to access some folders in the user’s library folder.
Astropad Studio – Pen Pressure not working
Atom Text Editor (1.27.2)
AutoMounter – App runs fine, but if you install the helper (v1.3.2) it causes the desktop to hang. Had to go into recovery to remove the helper. Emailed the dev.
CodeKit App (launches, but interface bugs make it unusable)
Compressor (4.4.1) – Can’t switch between tabs in the sidebar and therefore can’t customise encoding settings. Also erroneously displays the text “ProLabel” on the About window.
DEVONthink Pro Office 2.9.17 (crashes shortly after start)
Final Cut Pro X (Rendering takes a significantly longer time in Mojave)
Hyperdock v1.7 (it took a few reboots to get working; had to manually add to Accessibility in System Preference; reports “Unsupported Operating System” when opening the config in System Preferences)
LogMeIn App works but LogMeIn Safari Plug-In no longer works
MacGo Blu-ray Player (2.17.2) – Very occasional stutter/pause – not sure if this is due to running on MacBook Pro 2016 13″ TB 3.3Ghz i7, 16GB RAM from disk image on USB-C ->USB 3 external hard drive or an app issue.
Mamp Pro (4.5.0) – random freezes and beach ball at random points every little bit. Useable but annoying.
Microsoft OneDrive (runs and works, but pegs CPU usages to 100% until its quit)
OmniFocus 2.12.3 – Works fine, slight cosmetic anomaly in toolbar display which is “grayed out”
RealVNC Server – viewing is OK, but no remote control. Apple Screensharing works
Reeder (works, but crashes often)
RoyalTSX v3.3 (hangs randomly in Preferences and when trying load new documents, crashes when exiting an RDP session)
ShimoVPN (It starts up but won’t connect to anything — pptp)
SpamSieve (make sure to update to current beta before installing 10.14)
Splashtop Business (workable but very slow)
ThemeEngine – requires a little zooming in on elements to make them appear perfect in view. Can save .car files just fine.
Ulysses 2.8.3 (standalone version, pre-subscription) – works and iCloud sync is functional, but there are display anomalies in Ulysses’ dark mode.
Wifi Explorer (loads and works fine, but no wifi data is displayed)
X-Plane 11: Purchased aircraft crash upon loading, built in ones work fine.
Zoom Outlook Plugin (4.3.5278) – doesn’t show the plugin when creating Outlook Meetings
Lightrooom – The application crashes when trying to import from an SD card. Other functions seem to work
Whether it’s on the news or in the abundance of emails you’ve received from retailers updating their privacy policies, you’ve probably heard of GDPR. Implemented on the 25th of May 2018, it promises to shape software for the foreseeable future by giving consumers more control over how their personal data is used.
As consequence, multiple organisations have had to adapt their policies to comply with the new law, including Apple.
At their Worldwide Developers Conference, they announced the next wave of software called ‘MacOS 10.14 Mojave’ for Macs and ‘iOS 13’ for iPhones and iPads – a new update with ramped up security that’s due to hit our gadgets this fall.
So, what’s new in Safari for Mojave?
Apple privacy rules have always been pretty tight, but they are getting even tougher with this year’s instalment.
Like all Apple software updates, transition is never easy.
Mojave makes massive changes to its internet browser Safari, helping to crack down on nosy websites and deter intrusive data mining – two things at the forefront of GDPR’s premise.
It’s nice to feel protected, so here are some of the most notable advancements providing you with some handy usage tips.
Intelligent Tracking Protection
Mojave imposes new restrictions on online tracking technology, making tracking protection easier to discover, easier to use and more nuanced.
Many websites have used tools such as likes or comments as a pathway to tracking users without their permission, ironically going ‘under the radar’. “This year, we’re shutting that down”, said Craig Federighi, Apple’s vice president of software engineering.
Apple’s intelligent tracking protection last year prevented third-party cookies, but this time they’re tightening the noose – intelligent tracking protection 2.0 is even more ruthless with eradicating cookies on websites with tracking abilities.
This restricts the amount of data companies can collect, with permission being required for access to information that was once readily available.
There is also changes to system configuration data, with the web browser presenting a simplified process when users access the web. Safari will reduce the amount of information it shares with websites, for instance, any installed fonts or plugins.
This eradicates more tools websites traditionally use to fingerprint users and makes it increasingly harder for data trackers to follow the combination of parameters used for tracking purposes.
In a world where patience is a virtue, so too is data. As busy people who want things done at the click of a mouse, we’d all love to have the same password for everything. But really, that’s not the best way to stay safe, as security experts never tire of explaining.
That’s why Mojave and iOS 12 are gaining support for automatic strong passwords, with the new system enabling Safari to automatically create, autofill, and store passwords.
In addition, passwords on macOS Mojave will be flagged if they’ve been reused, making it easier for users to create unique passwords for each login and more difficult for hackers to gain access.
At first, it will feel like a monotonous irritancy, but once users grasp and embrace the new software, your information will be kept as hidden as Victoria’s Secret.
But, perhaps ourselves at Setapp were one step ahead. The app Secrets has been available since last year – storing important information such as passwords, credit cards and bank details.
As well as storing your precious data securely, Secrets uses impressive predictive analytics to boost your productivity.
By automatically filling in logins on Safari or Chrome, you can forget about copying and pasting, or scratching your head trying to recall which password you used for which website.
Use Touch ID for All Passwords
With the release of macOS 10.14.4, Safari makes it easier to access password-protected sites. Now it takes only one touch.
With your finger, add Autofills in Safari when signing in for the first time. Simply choose the option from the drop-down menu and put your finger on the Touch ID power button.
To activate Touch ID for your passwords, open System Preferences > Touch ID > Safari AutoFill. The option of Safari Touch ID will now appear once you click on any password-protected field. Unbreakable shield for your sensitive information.
Enhanced Permission Policies
There’s no forgetting the webcam scandal of last year, with FBI’s Director James Comey advising the public to cover their laptop cameras amid suggestion of mass-hacking. But, if you feel like a slice of gorilla tape or a measly band-aid won’t suffice as a shield of privacy, Apple has your back.
Mojave is extending privacy protections to the camera, microphone and other sensitive user data, preventing apps or websites from being able to use your camera or microphone without permission.
When an app or website first tries to access these features, you’ll be presented with a dialogue box that says “[app name] would like to access the [microphone or camera]”, prompting you to allow or deny.
Apple also announced that other categories of data, such as your mail database and message history, will be protected in a similar manner to Mojave’s camera/microphone permissions.
With the new software, apps will need to obtain user consent for all API and direct access to these resources, with users able to access their security preferences in the Security section of System Preferences.
There’s no doubting that Mac is front-running the web privacy push, but it’s not alone. Other search engines are adapting their policies, with Mozilla Firefox integrating a tracking protection widget into its main toolbar, and Brave Software taking new measures to ensure your information is kept your own.
Once overlooked, user privacy is now a growing priority for many companies, and in light of recent data mining scandals, it’s for good reason.