Understanding Mac OS X Authorization Philosophy

Due to the mach microkernel, you will see some different behavior from standard UNIX, such as it is not separated from the standard UNIX kernel. You can get some things out of the system going the mach route that you wouldn't be able to get from a standard UNIX system. For example, there are ways to get root privilege by going through the mach passport facilities.

Authorization API

In this case the focus in on authorization, not capability (authentication), which is concerned only about whether to allow a privileged operation to proceed. The /etc/authorization file is where an administrator can set authorization rules.

The authorization APIs are extensible with plug-ins and can be two-way with Pluggable Authentication Modules (PAMs). Using this method, the applications never need to present anything unusual to the user. They all use these APIs to talk to the SecurityServer daemon, so the applications never see the administrator password. Finally the authorization APIs enable you to do single sign-on and selective single sign-on. That's why in certain instances you don't have to type your admin password if you have already done so in the last 5 minutes.

Keychains

Whether you know it or not, as a Mac OS X user you have at least one keychain, because the system makes one for you when you log in for the first time. The keychain is a file in your home folder where you can put secret information such as passwords, private and public keys, and sensitive notes. This information is encrypted and protected with CDSA access control lists (ACLs), and is stored in a database with extensible schemas. A system daemon, SecurityServer, manages the data in a secured memory space.

Administrative User Concepts

Mac OS X allows for three types of user accounts: standard user, administrator, and system administrator (root).

Standard Users

Standard, or nonadmin, users can use a basic set of applications and tools. They are limited to making configuration changes that affect only their own accounts, such as what applications and files are opened when the user logs in and what picture is displayed as the user's background pattern. A standard user cannot make changes to any systemwide settings, such as the Network, Date & Time, Sharing, Accounts, Security, Energy Saver, Startup Disk, or Print & Fax panes of System Preferences. A standard user is also restricted from using Directory Access and NetInfo Manager to change configurations.

If a standard user attempts to make a systemwide modification, the user will need to provide the user name and password of an admin user before the changes can be made.

Administrator

An administrator, or admin user, has basic use of the tools used to configure and customize Mac OS X. (The initial local account configured in Setup Assistant is an admin user.)

One of the most powerful attributes of an administrator is that this user type can change settings on any of the System Preferences panes. An administrator can make changes using certain utilities, such as NetInfo Manager, and can also install applications and resources that all users on the system can use.

System Administrator

A system administrator, also called superuser or root, has read/write access to all settings and files on the system, including hidden system files that a regular administrator user cannot modify.

By default, system administrator is disabled. The user exists, but you can't log in using that account. Mac OS X was configured this way to help secure the computer and avert unintentional deletion of important files and folders. System administrator can be enabled using NetInfo Manager, single-user mode, or the command line. When you view items owned by system administrator in the Finder, in the Info window, and with Is at the command line, you will see the owner as "system." When you view processes owned by system administrator in Activity Monitor, you will see the owner as "root."

Certificate and Trust Management

Mac OS X also embraces the X509 certificates and includes several of them by default. Additional certificates are added to the system keychain files. A default set of X509 anchors are also included and accessible by the keychain or by using the certtool and/or the security command-line tools.

Open Directory Authorization

Kerberos provides secure authentication services using a ticket system, allowing for a seamless end-user experience. Also, Kerberos authentication works cross-platform, meaning that your Mac OS X computers can use existing Active Directory Kerberos services, even if they are served from another platform. There are three main players in a complete Kerberos transaction: the user, the service that the user is interested in, and the key distribution center (KDC). The KDC is responsible for mediating between the user and the service, creating and routing secure tickets, and generally supplying the authentication mechanism.

Kerberos introduces the notion of a realm, which is a specific database or authentication domain. Each realm contains the authentication information for users and services. The users and services are called Kerberos principals.

For a service to take advantage of Kerberos, it must be kerberized, which means that it can defer authentication of its users to a KDC. Mac OS X Server not only provides a KDC when configured to host a shared Lightweight Directory Access Protocol (LDAP) directory, but it also provides a kerberized login window, Hypertext Transfer Protocol (HTTP), Mail, File Transfer Protocol (FTP), Apple Filing Protocol (AFP), virtual private network (VPN), XGrid, and Secure Shell Protocol (SSH) services.

The default edu.mit.Kerberos file does not include logging parameters. If the logging parameters are added, the log filenames are arbitrary and the files have to be manually created.

When a user account in the LDAP directory is configured to use the Open Directory password type (in Workgroup Manager), both the user account and the authentication server on the KDC hold a common user key. Keys are used to encrypt and decrypt any messages sent over the network.

Note

The Kerberos implementation in Mac OS X is based on Kerberos version 5.