Running Privileges
So, we have seen a little bit about security, let’s focus on the topic a little longer.
The actual way applications are ran, varies enormously from desktop to phone. On desktop applications can run with administrative privileges. On the phone apps are ran inside a sand box. That’s why we are going to talk a little while just for desktop development.
So, one of the most important differences between the way apps run in the desktop and the phone is that, on the desktop, they can run with different privileges. In the Unix world, users have different privileges to work with different files and directories. For instance, you can’t write the the System file unless you have administrative privileges. The same is true for applications, and how they handle the environment. Applications can run as administrative, thou, usually, this is not a good idea. For the most part, the vast majority of apps does not need to execute with administrative privileges. The rule of thumb is to never run with privileges higher than the one that the execution really requires, and limit the damage an attacker can inflict.
Don’t ever use AuthorizationExecuteWithPrivileges API, this is the easiest way to introduce security bugs.
But what if there is a real need to execute some code as administrative? In that case, Apple recommends to factor the function out of the main app, and run as a background daemon with the appropriate privileges. This way the actual code is execute without interaction of a rogue user.
An important consequence is that, a well crafted app will run seamlessly for any type of user, including an standard user (and even a guest). If it needs to execute some administrative task, the application can gracefully let the user knows that he or she is not authorized, and that’s it. Compare this with an application that refuse to be run for a standard user because somewhere hidden by many layers of code, there’s the chance to require administrative privileges. When the application is run by a standard user, it just need to work.
A corollary of that, is that developers should not rely on special capabilities of administrators. Which for the most part means don’t write to protected directories, like:
/Applications(including the app bundle)/Applications/Utilities/Library/*(including/Library/Application Supportand/Library/Preferences)
The thing is that, not only usability breaks, but Apple is continually tighten the OS, and future releases might brake if they rely on some privilege functionality.
Installation is a complex issue here, because we might require a serial code, to let the app run, or we might need to write to some protected directory. Well, the solution is to use an installer. The obvious solution is to use PackageMaker and the Apple Installer.
