Mojave Privacy Protection Aftermath
Months later, the issues stopped (or at least people stopped reporting them). I can’t say whether some sort of bug was fixed or if people are just now more familiar with how all the new privacy protections work. I’m leaning towards a bug of some sort as the reports have stopped altogether; I’d expect the occasional report of confusion if it was just a knowledge thing.
[…]
Regarding unit tests, it seems that changing my unit tests to run within an app, and adding the appropriate usage strings to the test app, was enough to get them to run.
[…]
At least, there seems to be one way as a dev to be able to make sense of things. Accessing protected directories (for instance, by using
access()) will fail with anEPERMerror. This differs from accessing a directory protected by UNIX permissions. In those cases, you will get anEACCESSerror. While that’s great for differentiating between the two cases what’s unclear to me is if there are other situations, outside of Mojave privacy protections, that would give me anEPERMerror.
Imagine playing a team sport, and midway through a match the referee tells you that all the rules have changed, but they’re not telling you how, just that what you have been doing so far has been banned – in part.
[…]
For the last five months, I have looked high and low in Apple’s developer and user documentation for an official account of this, and information as to how TCC determines the Attribution Chain, which in turn informs us – developers, sysadmins and users alike – which app or tool we should add to the Full Disk Access list.
You already know the answer: Apple has not even mentioned any of this. Mojave’s privacy protection is undocumented, by Apple at least.
Here’s an interesting Mojave support document. I didn’t know that you can use a configuration profile with the “SystemPolicyAllFiles” key set to automatically grant full disk access to apps. Convenient!
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
tccutilintentionally give users, sysadmins and developers almost no help. Most of the lists in the Privacy pane aren’t directly controlled by the user, and alltccutilseems able to do is wipe the contents of those lists. When you have a problem, you’re stuffed.[…]
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.
I’ve had lots of customers try to give an app Automation access or Full Disk Access, but find that it just doesn’t work or doesn’t stick. This page from the SpamSieve manual documents the different levels of resets that you can do to fix the problem: tccutil, manually deleting the TCC database (requires temporarily turning off System Integrity Protection), and reinstalling macOS. These are crude remedies, but fortunately they do work.
Previously:
- Mojave’s New Security and Privacy Protections Face Usability Challenges
- AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms
- Apple Event Sandboxing in macOS Mojave Lacks Essential APIs
- Apple Events Usage Description
Update (2019-02-07): Isaiah Carew:
Mojave includes many more system level protections to keep out malware. But with this security comes some annoying side effects. One that hit me recently is that I can’t attach Instruments to some apps. This has made plugin development difficult, particularly because RapidWeaver is one of those apps.
Update (2019-02-12): Sergiu Gatlan:
In that post, he also mentioned privacy issues present in the implementation of the /usr/bin/tccutil tool, as well as the possibility to piggyback other apps who have been previously granted access by the user to access sensitive data or locations. The Automator issue was fixed by Apple with the release of macOS Mojave 10.14.3 Supplemental Update on February 7, but the other two are still unpatched.
Update (2019-02-27): See also: Bryan Jones (via John Gruber).
Update (2019-06-20): Peter N Lewis:
So I have descended to the point of adding specific assistance for Mojave security setting bugs. “yes, yes, I know you told the system to grant Keyboard Maestro permission, but Mojave does not really think you meant it”. Sigh.
17 Comments RSS · Twitter
I continue to get issues with people who already have Keyboard Maestro installed and working and then upgrade to Mojave. The accessibility permissions are not updated correctly in such an amazing way that: a) the system preferences show Keyboard Maestro has accessibility permissions, and b) the system API tells Keyboard Maestro it has accessibility permissions, and yet c) Keyboard Maestro does not in fact have accessibility permissions. And the solution - toggle the checkboxes off and then on again. How can this be part of any security system? How secure can it be if it is so broken from the start?
Just spent an hour testing some 10.14-aware amends to the venerable py-appscript. After the first 50 minutes squelching all my own bugs, which were many and varied—Unit tests? QC? Code review? Pah! Ad-hoc bodging all the way, baby!—it still didn’t work right.
Did a quick googleduckbing, and bugger me, turns out $1Tn global tech titan APPL is even lazier and less competent at coding and testing than I am. And I’m a burned-out amateur now running on coffee fumes and cash found down the back of the sofa, so what’s their excuse?
My release bugs impact a few dozen/hundred users (if that) and reactive fixes get turned around in minutes/hours/days. Theirs affect *hundreds of millions* and fixes take months/years/ever. AEDeterminePermissionToAutomateTarget is not a complicated function; there’s only three or four execution paths to be exercised to be reasonably confident it’s fit for purpose. Even 10 minutes of quick-n-dirty ad-hoc testing during development would shake out such simple logic errors (mine did).
Security is Hard. Trust is even Harder. This level of quality says they’re not even trying.
And mind, these 10.14 enhancements are just to improve basic protection for everyday non-technical App users. Don’t get me started on just how worse-than-useless App-level authorization is at protecting professional users who rely on apps like Terminal to run scripts from multiple sources. I’ve been thinking a lot recently about how to architect a modern AppleScript/Automator successor with secure script-level sandboxing, and it’s not even rocket science. But I’m also seriously debating whether doing any more development work on Apple’s platform is just completely wasting *my* time.
Nadella’s Microsoft is looking a better professional prospect year by year.
Impressively borked. Not only does the askUserIfNeeded option give incorrect results, theEventClass/theEventID parameters are ignored too.
e.g. If user has previously denied permission to TextEdit then:
aem.Application('/Applications/TextEdit.app').permissiontoautomate(
eventclass=b'core', eventid=b'setd', askuserifneeded=True)
throws MacOSError(-1743) (errAEEventNotPermitted) as expected. Alas:
aem.Application('/Applications/TextEdit.app').permissiontoautomate(
eventclass=b'aevt', eventid=b'quit', askuserifneeded=True)
throws errAEEventNotPermitted too, despite standard `open`, `quit`, etc. events always being allowed (and indeed work fine when used).
How much do Apple pay their own developer staff again? Cos us users really deserve a cut of that for doing their damn jobs for them.
..
Off to spend another couple hours of my time writing up detailed Radar tickets containing all the fecking code tests they should’ve done themselves, like I don’t have pressing work of my own to be doing. I’ve built the world-beating F1 racing V8 of automation engines, and the damn thing’s mounted atop a clown car.
And folks wonder why I threw in the towel on appscript development.
I recently discovered a bug where Xcode was causing my app to fail in the debugger with said error "errAEEventNotPermitted" for AppleScripts, even though the app had all permissions for AppleScript.
But when launched outside the debugger, the exact same binary worked perfectly, as it should.
No, Apple no longer does any quality control. Their bug numbers are incredibly high, but they are busy drawing new emoticons instead of fixing the bugs, it seems.
@Norbert There’s also an Xcode bug where you get errAEEventNotPermitted (instead of a prompt to grant Xcode access) if you have a build phase that invokes a command that sends an Apple event.
@bob: Think I saw that atop a flying pig once.
That said, there is a distinction between “works acceptably well” and “this is just embarrassing”.
And when even a sloppy hack like me can see at a glance this feature was not fit to ship, it makes you wonder what cultural failures permitted it to do so, and to what extent those cultural failures are now systemic.
As I say, achieving Trust is really Hard. Throwing it all away though, that’s easy AF.
All of this has happened before. All of this will happen again.
[…] work as well as they used to. As a developer, I spend too much time working around OS bugs and breakage—in other words, preventing my apps from getting worse rather than actually making them […]
> So I have descended to the point of adding specific assistance for Mojave security setting bugs. “yes, yes, I know you told the system to grant Keyboard Maestro permission, but Mojave does not really think you meant it”. Sigh.
Personally, I've added that kind of things (because of Apple's bad UX when it comes to security):
"NSCalendarsUsageDescription" = "No, Packages does _not_ want to access your calendar. But if you need to use files located in your \"Library/Calendars/\" folder for your installation packages, you will need to allow Packages to access your calendar.";
