At its core, Carbon Copy Cloner is a product that is designed to make bootable backups of your Mac's operating system. In order for CCC to be able to make copies of system files, CCC needs to have the privilege of copying files that can't be read nor written by just any user – CCC requires elevated privileges to copy macOS system files. Likewise, CCC is often tasked with copying the data associated with multiple users. macOS prevents you from accessing files that belong to other users. If you, as the administrator of the Mac, want CCC to back up everybody's files, then again, CCC requires elevated privileges.
Acquiring elevated privileges on macOS
There are a few different ways to perform a task on macOS with elevated privileges. The simplest – and least secure – method to do this would be to prompt the user to authenticate when he opens the application, and then relaunch the application as the "root" user. The application would then have all of the privileges it needs. This would grant far too much privilege, though, because it also gives the user (or malware that is exploiting the application) privileged access to other users' files.
A better way to securely acquire elevated privileges is to isolate the code that requires those privileges into a separate, "faceless" application. This is a common practice known as privilege separation. Even here, though, there is a right way and a wrong way for the isolated application to gain elevated privileges. The antiquated technique is for the parent application to ask for administrator authentication, then change the owner of the privileged application to the root user, then set a special mode on that application that allows that application to run with the privileges of the owner of the application (root). While this is a popular technique on Linux and much, much older versions of Mac OS X, there is still a significant potential vulnerability with this approach – any user can open that privileged application and potentially use it as a puppet to perform privileged tasks. Apple specifically discourages this practice:
setuid and setgid bits for the executable file, and sets the owner and group of the file to the privilege level it needs (often with the root user and the wheel group). Then when the user runs that tool, it runs with the elevated privileges of the tool’s owner and group rather than with the privileges of the user who executed it. This technique is strongly discouraged because the user has the ability to manipulate the execution environment by creating additional file descriptors, changing environment variables, and so on, making it relatively difficult to do in a safe way.Adhering to a higher standard of security
Starting in Mac OS X 10.6 (Snow Leopard), Apple introduced a more secure paradigm for performing tasks with elevated privileges. Rather than blindly granting privileged access to an application, developers can ask the system to install a "privileged helper tool". macOS then invokes the privileged helper tool on demand, and the calling application can only communicate with the helper when it has met stringent requirements:
- The calling application and the privileged helper tool must be code signed (and valid)
- The calling application must be one of the applications that is specifically approved to make requests to that specific helper
- The calling application must have a valid authorization reference
These requirements prevent unauthorized use of the helper tool and they prevent maliciously modified applications from making requests to the helper tool.
CCC has leveraged a privileged helper tool since version 3 and Mac OS X Snow Leopard – right from the start. This architecture is not only more secure and future-proof than using setuid binaries, it also affords us, for example, the ability to perform backup tasks when no users are logged in to the system.