Update: Following my post a few weeks ago, I thought I’d look deeper into how Dropbox was getting around Apple’s security. After a little digging around in Apple’s vast documentation, it occurred to me to check the authorization database and see if that had been tampered with. According to: In a policy-based system, a user requests authorization—the act of granting a right or privilege—to perform a privileged operation. Convert publisher doc for macbook. 10 best antivirus for mac. Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server—used to obtain the user’s password or other form of identification, which also ensures consistency between applications. The Security Server—a Core Services daemon in OS X that deals with authorization and authentication—determines whether no one, everyone, or only certain users may perform a privileged operation. The list of authorization “rights” used by the system to manage this “policy based system” is held in /var/db/auth.db database, and a backup or default copy is retained in /System/Library/Security/authorization.plist.

On the mac I have at least 400GB available, so this shouldn't be the problem neither. On my MacMini, Dropbox is installed as well and there I don't have any issues. But obviously Dropbox was already installed before I upgraded to High Sierra and since I have no SSD in the MacMini the new file system of High Sierra wasn't applied. At the time, Dropbox said it was working with Apple to reduce its dependence on elevated access in macOS Sierra, and would respect when people disable the app's Accessibility permissions, but now.

Looking at the default with defaults read /System/Library/Security/authorization.plist we can find that there is an authorization right for System Preferences’ Accessibility list, which says: 'system.preferences.accessibility' = { class = user; comment = 'Checked when making changes to the Accessibility Preferences.' ; group = admin; shared = 0; timeout = 0; That file’s comments also state that “The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false if not specified.” In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences. Is it possible then, that Dropbox had overriden this setting in the auth.db?

Let’s go and check! To see what the current policies are, you have to actually read the sql database in /var/db/auth.db. There’s various ways of doing that, but the easiest for me was to access auth.db through the command line using the security tool. Issuing the following command in Terminal will return us the currently active policy for Accessibility: security authorization read system.preferences.accessibility On my machine, this returned: Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac. Security on OS X is a complex beast, however, and there are other authorization protocols at work. One that I already knew of is tccutil.

If you issue man tccutil in Terminal, you’ll see this: tccutil(1) BSD General Commands Manual tccutil(1) NAME tccutil — manage the privacy database SYNOPSIS tccutil command service DESCRIPTION The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data. One command is current supported: reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. EXAMPLES To reset all decisions about whether apps may access the address book: tccutil reset AddressBook Darwin April 3, 2012 Darwin (END) I had heard of a hack of this utility that was related directly to adding apps to Accessibility list over a year ago when I stumbled across this. In short, what that hack suggests is that you modify tcc directly by inserting an entry into the sql database located here /Library/Application Support/com.apple.TCC/TCC.db. You can read the current list with the command: sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db 'select * from access'. To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue: sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);” (*note the code given on the stackexchange page isn’t quite correct for the latest builds of the mac operating system, in which the access table now has 7 columns and so requires and extra “NULL” on the end as shown above). I tested this with several of my own apps and found it worked reliably.