---

Permissions

An important aspect of security on a computer system is the granting or denying of permissions (sometimes called access rights). A permission is the ability to perform a specific operation such as to gain access to data or to execute code. Permissions can be granted at the level of directories (folders), subdirectories, files or applications, or specific data within files or functions within applications.

Permissions in Mac OS X are controlled at many levels, from the Mach and BSD components of the kernel, through higher levels of the operating system, and—for networked applications—through the networking protocols.

This section introduces the basic features of permissions at all of these levels in Mac OS X.

In this section:

Mach Port Rights
BSD
ACLs
Mac OS X
Network File Systems

Mach Port Rights

At the deepest level of Mac OS X system architecture, the basis for the operating system’s built-in security features is provided by the Mach and BSD components of the kernel. This section provides only a very brief and cursory introduction to Mach. For more information on Mach in Mac OS X and Mach programming, see Kernel Programming Guide.

Mach security is based on ports and port rights. A Mach port is an endpoint of a communication channel between a client who requests a service and a server that provides the service. Mach ports are unidirectional; a reply to a service request must use a second port.

A port has a set of associated port rights, which are owned by tasks. A port right specifies which task can use that port. Each port has one receive right, the owner of which can receive messages on that port. Each port also has one or more send rights; the owners of the send rights can send messages to the port. Rights can be transferred between tasks by being attached to a message.

A single task (or other Mach object, such as a thread or the computer itself) may have multiple ports that provide access to resources it supports. For example, a task might have a name port and a control port. Access to the control port allows the task to be manipulated. In contrast, access to the name port merely allows the client to obtain information about the task or perform other nonprivileged operations on it.

Each process has a port right namespace, which maps small integers known as port right names to their corresponding port rights. A port right name is meaningful only within that task’s port right namespace. A task can transfer a port right to another task by sending it the corresponding port right name. However, unless it sends the name correctly, the receiving task won’t be able use the right. The only way to transmit a port right between two tasks is by sending a Mach message and attaching the right name to that message using the correct syntax and message structure.

When you use Mach to create a task, Mach returns a port right name that references a send right for the port (the receive right for a task port is always owned by the kernel). You can send messages to this port to start and stop the task, kill the task, manipulate the task’s address space, and so forth. Therefore, whoever owns a send right for a task’s port effectively owns the task and can manipulate the task’s state without regard to BSD security policies or any higher-level security policies. In other words, an expert in Mach programming with local administrator access to a Mac OS X machine can bypass BSD and higher-level security features. Therefore, it is very important to use strong administrator passwords, keep them secure, and control physical security for any computer containing sensitive information.

BSD

The BSD portion of the kernel is the key place within the Mac OS X operating system that enforces access to applications and files. BSD security policies are visible to users in the Finder, in the form of the Ownership and Permissions information in a file or folder’s Info dialog (Figure 2-12).

The most familiar aspect of BSD security is the file system security policy, which controls access to files and folders (directories). BSD file permissions are described in many documents, including File System Overview. In addition to the file system security policy, BSD defines two other security policies used in special cases: the owner or root security policy, and the root EUID security policy. Each of these policies is described briefly in the following subsections.

The BSD security model is based on matching up attributes of an object (such as a file) with attributes of the process attempting to gain access to that object. For example, suppose a file has an owner ID of 1234 and the file permissions specify that the owner may have read and write access to that file. Suppose further that Alice has a user ID (UID) of 1234. When Alice attempts to read the file, BSD matches her UID with the file’s owner ID and grants Alice access to read the file.

Starting in Mac OS X v10.5, the kernel includes an implementation of the TrustedBSD Mandatory Access Control (MAC) framework. Mandatory access control—also known as “sandboxing”—is discussed in “Mandatory Acccess Control Framework.”

File System Security Policy

The file system security policy is used to control access to objects in the file system, such as volumes, directories, files, symbolic links, and devices. Each file system object has a user ID (the file UID, commonly referred to as the file’s owner), a group ID (the file GID, commonly referred to as the file’s group), and three sets of permission bits, known as owner, group, and other permissions. The first set of bits controls access to the object by the owner (any process whose effective UID is equal to the file UID), the second controls access by members of the group, and the third controls access by everyone else. Each bit set contains three bits: read, write, and execute (rwx for short). The effect of these bits differs for files and directories, as shown in Table 2-1.

Each process has three user IDs: the real user ID (RUID), effective user ID (EUID), and saved user ID (SUID). The RUID is always inherited from the user or process that executes the process. The EUID is normally the same as the RUID, but it can differ in special circumstances as described in “Owner or Root Security Policy.” In most cases, it is the EUID that BSD checks to determine permissions. The SUID is used by BSD to enable a privileged process to switch in and out of privileged mode.

Each process also has real and saved group IDs (RGID and SGID) and up to 16 effective group IDs (EGIDs), which work in a way analogous to the process’s user IDs.

For more details on these UIDs and GIDs, see The Design and Implementation of the 4.4 BSD Operating System by Marshall McKusick and others.)

Under the file system security policy, BSD determines the permissions applicable to a process accessing a file by comparing the process’s EUID and EGIDs with the UID and GID associated with the file. If the UIDs match, BSD grants the process the permissions specified for the owner. If the UIDs do not match, BSD checks whether the process is considered a member of the group identified by the file’s GID. If it is, then BSD grants the process the permissions specified for the group. If neither of these conditions is met, the process is granted the permissions specified for “other.”

Owner or Root Security Policy

The owner-or-root security policy is used to control execution of a few specific operations. Under this policy, a specific operation on an object can be performed by any process whose EUID is the same as the object’s owner or whose EUID is 0. The user with a UID of 0 is called the root user (also called the superuser) and a process running with an EUID of 0 is said to be running asroot.

In addition to the r, w, and x bits, each file system object also has three ancillary permission bits: setuid, setgid, and sticky. Normally, when a process executes a program, the resulting process has both its RUID and EUID set to the EUID of the process that executed it. However, if the program’s setuid bit is set, it runs with the EUID equal to the program’s file UID. Therefore, if the owner of a program is the root user, the program runs with an EUID of 0. The setgid bit has a similar effect: the process runs with an EGID equal to the program file’s group UID.

The sticky bit restricts the deletion of files in a directory so that only the owner of the file, the owner of the directory, or the root user can delete a file.

A user can change the permissions only on files owned by that user. Therefore, only the root user can set the setuid bit on a program owned by root. Because such a program runs with root privileges when executed by someone other than root, it can create a security vulnerability. Therefore, it is important to restrict the creation and use of such programs.

An example of where the owner-or-root security policy applies is the chmod system call, which is used to change the permissions of a file (including the setuid and setgid bits). Only the owner of the file or a process running as root can change a file’s permissions.

Root EUID Security Policy

Under the root EUID security policy, an operation can be performed only by a process with an EUID of 0. Such operations are sometimes referred to as privileged operations. Some of the common situations where the root EUID security policy applies are:

• Changing the owner of a file system object

• Binding TCP/IP sockets to low-numbered ports

• Making changes to the network configuration

• Certain I/O Kit operations

• Getting the Mach host privileged special port

Authorization Services and BSD Security Policies

Because a process running with an EUID of 0 has many special privileges, such a process can be a target of malicious hackers. To minimize such risks, you should factor your application into privileged and nonprivileged processes. See “Authorization Services” for more information and for references that describe and illustrate this technique.

Processes can change their EUID and EGID by calling setuid, setgid, and related system calls. For example, a process can run as root temporarily and then switch to a less privileged EUID to minimize exposure to malicious attacks. This technique is complicated by the confusing semantics of the setuid call and by the fact that these calls operate somewhat differently on different implementations of UNIX (including different versions of Mac OS X). For a detailed discussion of the issues involved, see Setuid Demystified by Chen, Wagner, and Dean (Proceedings of the 11th USENIX Security Symposium, 2002), available at http://www.usenix.org/publications/library/proceedings/sec02/full_papers/chen/chen.pdf. For more information on the system calls, see the man pages for setuid, setreuid, and setregid. (The setuid man page includes information about seteuid, setgid, and setegid as well.)

Mandatory Acccess Control Framework

The MAC framework provides fine-grained control of the ability of processes to access system resources. For example, you can prevent a process from connecting to any network, from writing any files, or from writing any files outside of specific directories. This feature, also known as “sandboxing,” limits the amount of damage that can be done by a malicious hacker that gains control of an application. For example, if an attacker takes control of an application that is sandboxed so that it can write files only to the folder /var/tmp, it is not possible for the hacked program to overwrite system files.

New processes inherit the sandbox restrictions of their parent.

The Mac OS X MAC framework is an implementation of the TrustedBSD MAC framework, documented in http://www.trustedbsd.org/mac.html. A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.

ACLs

Starting with Mac OS X v10.4, the Mach and BSD permissions policies are supplemented by support in the kernel for access control lists (ACLs). ACLs provide much more detailed control over permissions than does BSD. For example, ACLs allow the system administrator to specify that a specific user can delete a file but cannot write to it. ACLs also provide compatibility with Active Directory and with the SMB/CIFS networks used by the Windows operating system. For more information on ACL support in Mac OS X for different network file systems, see “Network File Systems.”

An ACL consists of an ordered list of access control entries (ACEs), each of which associates a user or group with a set of permissions and specifies whether each permission is allowed or denied. ACEs also include attributes related to inheritance (see “Inheritance of Permissions”).

File System Access Control Policy

You can use file system ACLs to implement more detailed and complex access control policies than are possible using only BSD permissions. They do so by using many more permission bits than the three used by BSD and by implementing both allow and deny associations for each permission for each user or group. Table 2-2 shows the permission bits used by ACLs. Compare these to the BSD permission bits shown in Table 2-1.

Notice that the right to change permissions is itself controlled by a permission.

ACLs and User IDs

One of the main reasons for implementing ACLs in Mac OS X is to support network file systems such as SMB/CIFS (see “SMB/CIFS”). In order to be able to identify users and groups throughout the network, each file or directory must have universally unique identifiers (UUIDs) in addition to the locally-unique UID and GID used by BSD. Each file or directory that has associated ACLs, therefore, has four associated identities, two to support BSD and two to support ACLs:

• user ID (UID)

• group ID (GID)

• owner UUID

• group UUID

Unlike BSD, which specifies three permissions for each file (one for the file’s owner, one for members of the file’s group, and one for everyone else), an ACL can specify different permissions for each ACE. Another contrast between ACLs and BSD is that, whereas in BSD the file owner must be an individual, in the ACL permission scheme the file owner can be either a user or a group. If a file is owned by a group, its GID (used by BSD) and group UUID are always coherent (that is, there is always a simple, 1:1 mapping between them). However, because BSD does not support the concept of a group as owner of a file, in this case the system assigns a special UID that identifies the file as owned by “not a user” and the owner UUID represents a group. If the file is owned by a single individual, its UID and owner UUID are coherent.

The owner of a file using an ACL has certain unrevokable permissions (read and write permissions) regardless of the contents of the ACL. If the file is owned by an individual, the group UUID associates a group with a file system object and affects the inheritance of certain ACEs (see “Inheritance of Permissions”) but does not confer any special permissions on the group.

Evaluating Permissions

Each ACE in an ACL either allows or a denies some set of permissions. It is very important to understand that a deny ACE is not the same as the absence of an allow ACE. Rather, the system evaluates the ACEs in sequence until either all requested permissions are allowed or any requested permission is denied. A request for authorization includes a credential (which identifies the requesting entity) and the permissions required for the operation. Mac OS X v10.4 and later evaluates permissions using the following algorithm (also, see “Inheritance of Permissions” for a discussion of inherited permissions):

1. If the requested permissions would change the object, and the file system is read-only or the object is marked as immutable, the operation is denied.

2. If the entity making the request is the root user, the operation is allowed.

3. If the entity making the request is the object’s owner, the requestor is given Read Permissions and Write Permissions access. If that is sufficient to satisfy the request, the operation is allowed.

4. If the object has an ACL, the ACEs in the ACL are scanned in order. (Those with deny associations are usually placed before those with allow associations.) Each ACE is evaluated according to the following criteria until either a required permission has been denied, all required permissions have been allowed, or the end of the ACL is reached:

   1. The ACE is checked for applicability. The ACE is not considered applicable if it does not refer to any of the requested permissions. In addition, the requesting entity must be the same as the entity named in the ACE, or the requestor must be a member of a group named in the ACE. (Groups may be nested and an external directory service may be used to resolve group membership.) Non-applicable ACEs are ignored.

   2. If the ACE denies any of the requested permissions, then the request is denied. (Note that Read Permissions and Write Permissions are granted to the object’s owner, regardless of whether allowed or denied by ACEs.)

   3. If the ACE allows any of the requested permissions, the system adds this permission to the list of granted permissions. If the granted permissions include all the requested permissions, the request is allowed and the process stops. If the list is not complete, the system goes on to check the next ACE.

5. If the end of the ACL is reached without finding all of the required permissions, and if the object also has BSD permissions, then the system checks the unsatisfied permissions against the BSD permissions. If these are sufficient to grant all required permissions, the request is allowed. If the permission requested has no BSD equivalent (such as “take ownership”), then it is considered still outstanding and the request is denied.

6. If the file system object has no ACL, then permissions are evaluated according to the BSD security policies, as described in “BSD.”

The credential of the requesting entity is equivalent to the effective UID (that is, the EUID) of the program attempting to open or execute a file. The EUID is normally the same as the UID of the user or process that executes the process., but it can differ in special circumstances (involving the setuid bit) as described in “Owner or Root Security Policy.”

Inheritance of Permissions

BSD permissions are assigned only on a per-file basis, so that the permissions assigned to a directory do not affect the permissions of a new file or subdirectory created in that directory. Although you can apply the permissions of a directory to enclosed items, doing so is a one-time operation. Any newly created files or subdirectories are not affected—they are created with default permissions.

With ACLs, by contrast, newly created files and subdirectories can inherit permissions from their enclosing directory. Each ACE on a directory can contain any combination of the following inheritance flags:

• Inherited (this ACE was inherited).

• File Inherit (this ACE should be inherited by files created within this directory.

• Directory Inherit (this ACE should be inherited by directories created within this directory).

• Inherit Only (this ACE should not be checked during authorization).

• No Propagate Inherit (this ACE should be inherited only by direct children; that is, the ACE should lose any Directory Inherit or File Inherit bit when inherited).

When it creates a new file, the kernel goes through the entire access control list of the parent directory and copies to the file’s ACL any ACEs that are marked for file inheritance. Similarly, when it creates a new subdirectory, the kernel copies to the subdirectory’s ACL any ACEs that are marked for directory inheritance.

If a file is copied and pasted into a directory, the kernel replicates the contents of the source file into a new file at the destination. Because it is creating a new file, the system checks the ACL of the parent directory and adds any inherited ACEs to whatever ACEs were in the original file. If a file is moved into a directory, on the other hand, the original file is not replicated and no ACEs are inherited. In this case, the parent directory’s ACEs are added to the moved file only if the administrator specifically propagates ACEs from the parent directory through contained files and subdirectories. Similarly, once a file has been created, changing the ACL of the parent directory does not affect the ACL of contained files and subdirectories unless the administrator specifically propagates the change.

In BSD, applying a directory’s permissions to enclosed files and subdirectories completely replaces the permissions of the enclosed objects. With ACLs, in contrast, inherited ACEs are added to other ACEs already on the file or directory.

The order in which ACEs are placed in an ACL—and therefore the order in which they are evaluated to determine permissions—is as follows:

1. Explicitly specified deny associations

2. Explicitly specified allow associations

3. Inherited associations, in the same order in which they appeared in the parent

Therefore, any explicitly specified ACEs take precedence over all inherited ACEs. For more information on how ACEs are evaluated, see “Evaluating Permissions.”

Because ACEs can be inherited, administrators can control the fine-grained permissions of files created in a directory by assigning inheritable ACEs to the directory. Doing so saves the work of assigning ACEs to each file individually. In addition, because ACEs can apply to groups of users, administrators can assign permissions to groups rather than having to specify permissions for each individual. Applying access security to directories and groups rather than to files and individuals saves administrator time and gives better file system performance in many circumstances.

For application programmers, it is important to note that the automatic inheritance of permissions from directories means that it is not necessary for an application to create an ACL for each new file it creates or to maintain inherited ACEs when a file is saved, because the kernel creates the ACL for the file using inherited ACEs. (Note that assignment and inheritance of BSD permissions are not affected by ACLs. If ACLs are not supported, the BSD permissions are used. For more information on the way permissions are evaluated when both ACLs and BSD permissions are set, see “Evaluating Permissions.”)

In Mac OS X Server v10.4, the server administrator can perform the following operations:

• Copy permissions from a parent directory to all files and directories below it in the hierarchy. This makes permissions uniform in the directory tree and should be used only for BSD permissions.

• Propagate permissions from a parent directory to all files and directories below it in the hierarchy. In this case, explicitly specified ACEs are unchanged and ACEs inherited from them are unchanged. Files and subdirectories inherit ACEs as if they had been newly created in place under the directories that have explicitly specified ACEs, as illustrated in Figure 2-13.

• Apply inheritance from a parent directory to a specific directory or file.

• Make inherited ACEs in directories explicit.

• Remove all ACEs from directories and files.

• Enable or disable ACLs on a volume.

The server GUI cannot directly manipulate ACEs of files. There is no GUI in the Finder to set or change ACEs. ACEs can be read and set both on the server and client using the command-line tools ls and chmod.

Mac OS X

This section discusses how Mac OS X uses BSD permissions.

The Root User

The root user owns many of the primary system processes and has unlimited access to the file system objects on the devices attached to the computer. For example, the root user can:

• Read, write, and execute any file

• Copy, move, and rename any file or folder

• Transfer ownership and reset permissions for any file

A major difference between standard BSD permission semantics and the Mac OS X implementation is that in Mac OS X the root user is disabled after system installation. In most cases, it is not necessary for an administrator to run as root (see “The Admin Group”). You may also assume root power by using the sudo utility. Although the sudo utility does not require you to enable the root user, you can use it only from the Terminal application; that is, you must have physical access to the machine to use it. See the sudo man page for more information on its use.

The root user should not be enabled on user systems. If your application needs to perform operations as the root user, you must use Authorization Services. For more information, see Authorization Services C Reference and Performing Privileged Operations With Authorization Services in Security Documentation.

Whereas most user permissions apply across networks, often the concept of a root user does not. In most cases, the root user is mapped to nobody—a special user with very little access. This prevents the root user on one computer from becoming the root user on another computer.

The Wheel Group

There is a special group in BSD called the wheel group. Membership in the wheel group confers on users the ability to become the root user by using the su utility on the command line. Users who are not in the wheel group can’t become the root user, even if they have the correct password. In Mac OS X v 10.3 and later, the wheel group is not used. Its functions have been assumed by the admin group.

The Admin Group

Mac OS X provides the admin group in place of the root user. A member of the admin group (referred to as an administrator) can perform almost all functions the root user can, and can do them using the Finder—that is, without resorting to the command line. The only thing the administrator is prevented from doing is directly adding, modifying, or deleting files in the system domain. An administrator can use special applications such as Installer or Software Update for this purpose, however.

The user who installs Mac OS X on a system becomes automatically the first administrator for the system. Thereafter, this user (or any other administrator) can use Accounts preferences to create accounts on the local system for new users and can grant administrative privileges to any user on the system.

Network File Systems

This section discusses the use of permissions by network file server protocols. Mac OS X supports four network file server protocols:

• AFP—Apple Filing Protocol, the principal file-sharing protocol in Mac OS 9 systems, used by AppleShare servers and clients.

• NFS—Network File System, the main file-sharing protocol used by UNIX systems.

• SMB/CIFS—Server Message Block/Common Internet File System, a file-sharing protocol used on Windows and UNIX systems

• WebDAV—Web-based Distributed Authoring and Versioning, an extension of HTTP that allows collaborative file management on the web.

AFP

If the AppleShare client and server both support AFP 3.0, the actual BSD permissions are transported over the connection. If the file or directory on the AFP server has an ACL, the ACL is transported over the connection and the effective permissions are displayed by the Finder. However, enforcement of permissions is done only on the server, not on the client. See “ ACLs” for more information on the Mac OS X implementation of ACLs.

If the connection is using AFP 2.x, you should be aware of the differences in how permissions work:

• BSD supports permissions on files, whereas AFP 2.x does not.

• BSD implements a “best match” permissions policy: if you’re the owner, you get the owner permissions; if you’re not the owner but you’re in the file’s group, you get the group permissions; otherwise, you get the other permissions. AFP implements a cumulative permissions policy: your permissions are the union of the permissions you derive from the owner, group, and other permissions. For example, if a folder is writable by the group but not by the owner, AFP permissions let the owner modify the folder but BSD permissions do not.

• BSD interprets the rwx bits for folders as shown in Table 2-1. AFP permissions define them as “See Files”, “See Folders”, and “Make Changes”. When dealing with an AppleShare 2.x server, the Mac OS X AppleShare client maps between these privilege models. A similar mapping applies when you connect to a Mac OS X server using an AppleShare 2.x client.

• ACLs are not supported by AFP 2.x.

AFP excludes a process having an EUID of 0 (that is, one running as root) from accessing any data over the network.

NFS

In general, NFS is not a secure protocol, because most NFS servers trust their clients. That is, if a client says that this file operation is done on behalf of user Bob, the server does the operation on behalf of user Bob. However, if you have root access on the client, you can pretend to be user Bob and access any of Bob’s files on the NFS server. To maintain some security, most NFS servers map the root user to a special user, nobody, which owns no files or directories. For this reason, if your EUID is 0 you can, in general, access only those files on an NFS server that allow access to “other”.

SMB/CIFS

SMB is a networking protocol for file sharing commonly used on Windows networks. CIFS is often used as a synonym for SMB. Samba is software that implements an SMB/CIFS server on UNIX. Therefore, this file sharing protocol is variously referred to as SMB, CIFS, SMB/CIFS, Samba, and Windows file sharing.

Mac OS X v10.4 and later implements SMB/CIFS-compatible access control lists (ACLs). Although individual users cannot set or alter ACLs, server administrators can do so. (Administrators can use the SMB server command line to manipulate ACLs, but only if both the client and server are bound to the same Active Directory domain.) However, enforcement of permissions is done only on the server, not on the client. See “ ACLs” for more information on the Mac OS X implementation of ACLs.

For Mac OS X v10.3 and earlier, all of the SMB access controls in Mac OS X are implemented on the server, not the client. Consequently, when a Mac OS X user mounts an SMB file server, the volume, directory, or file mounted appears in the Finder to allow read, write, and execute access and to be owned by the user. However, when the user attempts to open a folder or file, the server evaluates the user’s access permissions and either allows access or prompts the user for a new user name and password before granting access.

For more information on SMB/CIFS permissions and to learn how to modify their behavior, see the man page for SMB (man 5 smb.conf).

WebDAV

The WebDAV protocol is an extension to the HTTP protocol that allows users to write and edit web content remotely; that is, over a network connection. The Mac OS X WebDAV file system uses WebDAV and HTTP requests to access resources on a WebDAV-enabled HTTP server as files and directories.

The WebDAV protocol does not support users and groups. Furthermore, a WebDAV client cannot determine access permissions for files and directories on a WebDAV server before attempting to access them. Therefore, the WebDAV file system in Mac OS X sets the user and group IDs to unknown for all files and directories and the permissions default to read, write, and execute for everyone: user, group, and other.

When the WebDAV file system sends a request to a WebDAV-enabled HTTP server, the server determines whether authorization is required. If no authorization is required, the server accepts the request. If authorization is required, the server checks for authentication credentials (such as a user name and password) and, if they are present and correct, the server authorizes the client and allows access. If authorization is required and no credentials were sent or the credentials are not correct, the server rejects the request with a challenge for authentication. If the user cannot supply the correct credentials, the WebDAV file system refuses access.

For more information on the protocols used by the WebDAV file system, see the following documents:

• Hypertext Transfer Protocol—HTTP/1.1http://www.ietf.org/rfc/rfc2616.txt

• HTTP Authentication: Basic and Digest Access Authenticationhttp://www.ietf.org/rfc/rfc2617.txt

• HTTP Extensions for Distributed Authoring—WEBDAVhttp://www.ietf.org/rfc/rfc2518.txt

---