When you launch TinkerTool System for the first time, it will automatically integrate into the security model of OS X. This is necessary because the application can be used to perform critical operations in OS X, for example to alter or even delete operating system files. Only responsible system administrators which manage the computer’s installation should be allowed to perform such actions.
For this reason, TinkerTool System contains a safeguard which communicates with the security features of OS X. Under normal circumstances, TinkerTool System is restricted to behave like a normal user program and does not have any extended privileges. For example, it cannot use any system features which could affect more than the current user. However, certain maintenance functions require that TinkerTool System is allowed to act for the whole computer and all users. In this case, the built-in safeguard of TinkerTool System requests permission from OS X to temporarily use a system feature which needs extended privileges. As response to this request, OS X will completely “freeze” TinkerTool System and open a password entry panel in which you’ll have to enter a valid password for one of the system’s administrators. If the password is correct, OS X will allow TinkerTool System to continue and to execute the requested action. If the password was wrong, TinkerTool System will also continue, but will additionally receive the response that the permission was not granted and the current request is rejected. In that case, TinkerTool System cannot perform the action currently selected. With this design, it becomes impossible that an unauthorized person could misuse an application like TinkerTool System.
To further enhance security, the application additionally uses the concept of multi-tier privilege separation. When an operation with extended privileges needs to be executed, it won’t be the main application itself contacting OS X to ask for permission. Instead, two auxiliary programs, the privilege requestor and the privileged helper, each with specific rights independent of the main program, will fulfill the job. This way, a theoretical security breach in one of these components cannot easily spread into other parts of TinkerTool System. The following picture shows the overall design. All three components communicate on secure channels under supervision of OS X.
These policies strictly comply with Apple’s software guidelines for system utilities. Note that TinkerTool System doesn’t even “see” the administrator password when it is entered. All security-related interactions are directly handled and monitored by OS X. So even in the unlikely case a computer virus would attack TinkerTool System, trying to “eavesdrop” on your password entry in an attempt to store and steal the password, it would have no success, because only the specially protected core of OS X actually receives and checks the entered password information.
The first password entry is requested by OS X when you start TinkerTool System for the first time. This allows the tool to form the aforementioned trust relationship and protection mechanisms. Other password requests will follow as soon as you start an operation which needs extended privileges.
All mentioned security features are exclusively controlled by OS X. They have nothing to do with the registration or licensing of the software, but they are needed to avoid security holes in the operating system.
OS X automatically ensures that the user doesn’t need to enter the password too often. After a password has been entered, OS X will “trust” all applications started by the same user for an interval of 5 minutes.
The paragraphs below contain information for experienced system administrators. You can skip them during first reading.
As mentioned above, OS X usually “remembers” for 5 minutes that an administrator has entered a password successfully. This memory may even be shared by different applications running in the same user session. For example, after you have logged in as administrator you might see that some lock icons in several applications will be in the “open” position, so you won’t need to reenter your password. The locks will automatically close after the trust period is over. Some details can be controlled by the Security pane in System Preferences.
TinkerTool System lets you decide whether it should make use of this temporary caching of administrative credentials. By default, OS X will follow the standard policy to reuse a successful authentication when TinkerTool System first likes to execute a privileged operation A, and within 5 minutes likes to execute some other privileged operation B. As an alternative, TinkerTool System can instruct OS X not to reuse authentications. After that, OS X will ask for administrative authentication for each single operation TinkerTool System likes to perform. To change to this more secure policy, perform the following steps:
In this context, the term “operation” is meant to be interpreted as a connected procedure triggered by a single interaction of the user within TinkerTool System, e.g. a repair feature started by pressing an OK button. This procedure may internally consist of multiple smaller operations using different rights, e.g. first removing a system file and then creating a new one in its place. OS X won’t ask for re-authentication for these smaller operations, but only for the perceived operation as a whole.
The security component will be installed into the folder /Library/PrivilegedHelperTools which is Apple’s recommended folder to be used for such utility programs. The name of the component is com.bresink.system.privilegedhelper-tts. OS X will automatically launch and quit this program as needed, avoiding to let it run as a background service for an extended period of time.
You can choose to remove the security tool at any time without any traces. In this case TinkerTool System will lose its capability to access privileged system areas, so the program will be forced to shut down either. Perform the following steps to remove the component:
Just authenticating against the user credentials of an administrator might not be enough for the situation in some large organizations. Perhaps the user should be member of another group of specially trusted staff in order to be able to perform a certain operation, or maybe some security rules should be relaxed, so that non-administrative users get access to privileged operations, too. TinkerTool System follows Apple’s guidelines to internally work with named rights for each class of operations and to register these names with the Authorization Policy Database of OS X. This way, advanced administrators can fine-tune rights in the policy database as needed, connecting rights to specified authentication mechanisms. Details can be found in a separate chapter.