Section 2.14. Security

2.14. Security

We could informally define computer security as a condition wherein all computer resources are always used "as intended." However, it is impossible to exhaustively enumerate all of one's intentions, which will differ in any case from one personor one scenarioto another.^[76] We could express the notion of computer security in somewhat more concrete terms as follows: Security is the union of software, hardware, policies, and practices that allows a system and its users to achieve the following:

^[76] Surely, there could be situations that neither the designers of a system nor its users have thought of yet.

• Verify identities of users and system services

• Safeguard sensitive information (such as personal data, cryptographic keys, and passwords) during storage, transmission, and use

A definition of security could be reinforced by describing the absence of security, that is, insecurity. A computer system's resourcesincluding external, shared resources such as the networkare all vulnerable to attacks: from outside and often from within. We can think of a vulnerability as a potential for unintended usea result of a software bug, a design oversight or error, a misconfiguration, and so on. When exploited via attacks, vulnerabilities could lead to tangible or intangible damage. The following are examples of common types of potential damage:

• Leaking of sensitive data

• Modification of sensitive data

• Destruction of sensitive data

• Unauthorized use of a system service

• Denial of a system service so that its legitimate users cannot use it

• Disruption or degradation of any system operation in general

A system's resources could be misused without denying service to legitimate users or without causing any apparent damage to the system itself. For example, if a system's resources are lying idle, it can still be misused as a stepping-stone to infiltrate another system.

Now that we have an informal understanding of computer security, let us look at important security-related aspects and features in Mac OS X. Figure 234 depicts many of these features.

Figure 234. The Mac OS X security architecture

Figure 234 does not show some daemons that play security-related roles in the operating system. For example, lookupd caches and makes available a variety of information such as user accounts, groups, computer names, and printers. Another daemon, memberd, resolves group memberships and responds to membership API calls made by clients. Examples of these calls include mbr_uid_to_uuid() and mbr_uuid_to_id().

Mac OS X security features can be divided between those provided by the kernel-level and user-level security models. Additionally, a firmware password may be used on Apple computers in a potentially hardware- or model-dependent manner. We will look at Open Firmware password protection in Chapter 4.

2.14.1. Kernel-Space Security

The Mac OS X kernel security model consists of both Mac OS Xspecific and typical Unix-style features. The following are examples of the kernel's security-related features.

• BSD user and group identifiers (UIDs and GIDs) Traditional UIDs and GIDs form the kernel's most basic and least flexible means of security enforcement. Examples of BSD security policies based on UIDs and GIDs include ownership of file system objects; read/write/execute permissions on file system objects; operations restricted to processes with an effective UID of 0 (root euid policy); and operations on an object restricted to a process belonging to the object's owner or to a process with an effective UID of 0 (owner or root euid policy).

• Mach port rights Besides being an IPC channel, a Mach port may represent a variety of resources, examples of which include tasks, threads, memory ranges, processors, and other devices. Moreover, Mach is a capability-based system in which port rights determine which operations a task may or may not perform on a port. The kernel manages and protects ports, thereby ensuring that only tasks with the required rights can perform privileged operations.

• Auditing system The Mac OS X kernel implements an auditing system based on BSM (Basic Security Module), which is both a security audit format and an API used to track security-related events in the operating system.

• Process accounting System-level accounting for every process executed can be enabled or disabled using the accton command. When process accounting is enabled, the lastcomm command displays information about previously executed commands.

• Encrypted virtual memory The kernel can optionally use the AES algorithm to encrypt virtual memory pages that are swapped out to secondary storage.

• ACLs File system ACLs are supported for finer-grained and flexible admission control when using on-disk information. Per-file ACLs are implemented as extended attributes in the file system.

• Kauth Kauth is an in-kernel mechanism for the evaluation of ACLs. It is flexible and extensible, allowing kernel programmers to install their own callbacksor listenersfor authorization requests in the kernel. When an entity wishes to perform an operation on an object, all registered listeners are invoked and provided with contextual information about the requester's credentials and the requested operation. A listener may allow, deny, or defer the request. The latter essentially lets the listener opt out from decision makingit is up to the remaining listeners, and eventually the default listener, to allow or deny the request.

2.14.2. User-Space Security

Mac OS X provides a flexible user-space security model that is largely based on the Common Data Security Architecture (CDSA). CDSA is an open source security architecture adopted as a technical standard^[77] by the Open Group. It consists of a cryptographic framework and several layers of security services. Apple uses its own CDSA implementation, which is depicted in Figure 234.

^[77] The CDSA Specification was initiated by Intel Architecture Labs. The current standard is a cooperative work of many organizations and companies, including Apple and IBM.

CDSA helps in the implementation of security features such as encryption, fine-grained access permissions and user authentication, and secure data storage.

2.14.2.1. CDSA Plug-ins

The lowest layer of CDSA consists of plug-ins called by the layer above. CDSA plug-ins are allowed to call each other as well. Apple-provided CDSA plug-ins are shown in Figure 234. CDSA allows additional plug-ins to exist.

2.14.2.2. CSSM API

CDSA's core is a set of modules called the Common Security Services Manager (CSSM). The CSSM modules shown in the CSSM Managers block in Figure 234 together provide the CSSM API. The Authorization Computation Services Manager module shown within a dotted outline is not present in Apple's CDSA implementation.

2.14.2.3. Mac OS X Security APIs

Mac OS X applications normally use Apple's middleware security APIs that are built atop the CSSM API to access CDSA functionality. However, it is possible for an application to use the CSSM API directly. Examples of services provided by the middleware APIs include the following.

• Keychain Services provides secure storage for certificates, keys, passwords, and arbitrary information.

• Secure Transport provides secure network communication through implementations of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols.

• Certificate, Key, and Trust Services, respectively, create, access, and manipulate certificates; create encryption keys; and manage trust policies.

• Authorization Services is used as the primary API by applications to authorize access to specific actions^[78] (e.g., creating a file in a restricted directory) or data.

  ^[78] Applications can use Authorization Services to implement fine-grained authorization.

2.14.2.4. Security Server and Security Agent

As shown in Figure 234, Authorization Services communicate with the Security Server, which then uses the CDSA APIs. Besides authorization, the Authorization Services API also handles authentication if required.

Authorization involves asking whether a given entity is allowed to perform a given operation. Before the question may be answered, the requester is typically required to authenticatethat is, to prove his or her identity. Then it is determined whether the entity in question has the appropriate permissions.

The Security Server^[79] (/usr/sbin/securityd) acts as an arbiter of many types of security-related operations and accesses. For example, fine-grained authorization of arbitrary operations by applications is based on rules contained in the /etc/authorization policy database. The Authorization Services API includes functions to add, delete, edit, and read policy database items. When an application requests a rightfor example, com.osxbook.Test.DoSomething^[80]it makes an authorization call. The call is routed to securityd, which consults the policy database. securityd attempts to find a rule that exactly matches the requested right. If none is found, securityd looks for wildcard rules that may match, in the order of the longest match first. If there are no matches at all, securityd uses the generic rule, which is used for rights that do not have any specific rules. If the user authenticates successfully, securityd creates a credential with an expiration period of 5 minutes.^[81]

^[79] The Security Server is not part of CDSA.

^[80] Rules and rights are conventionally named in the policy database using a reverse DNS naming scheme.

^[81] The expiration period is specified through the timeout key in the policy database.

The Security Agent application (/System/Library/CoreServices/SecurityAgent.app) is the user-interface handler for securitydthe latter does not interact with the user directly but launches Security Agent as a separate process, which in turn displays a username and password request dialog. Thus, Security Agent enforces GUI interaction, which normally warrants physical presence.^[82]

^[82] Physical presence is warranted unless the system is being driven remotely through a product such as Apple Remote Desktop. Beginning with Mac OS X 10.4, an application can authorize a user by passing in a username and password to the authorization functionwithout displaying the authentication dialog box.

2.14.2.5. Using Authorization Services

Figure 235 shows a program that requests a right named com.osxbook.Test.DoSomething. If the right doesn't exist in the policy databasewhich should be the case when the program is run for the first timeit sets up the right based on an existing standard rule called kAuthorizationAuthenticateAsSessionUser. The latter requires the user to authenticate as the session ownerthat is, the currently logged-in user.

Figure 235. Using Authorization Services

// testright.c #include <stdio.h> #include <stdlib.h> #include <CoreFoundation/CoreFoundation.h> #include <Security/Authorization.h> #include <Security/AuthorizationDB.h> const char kTestActionRightName[] = "com.osxbook.Test.DoSomething"; int main(int argc, char **argv) {     OSStatus            err;     AuthorizationRef    authRef;     AuthorizationItem   authorization = { 0, 0, 0, 0 };     AuthorizationRights rights = { 1, &authorization };     AuthorizationFlags  flags = kAuthorizationFlagInteractionAllowed |\                                 kAuthorizationFlagExtendRights     // Create a new authorization reference     err = AuthorizationCreate(NULL, NULL, 0, &authRef);     if (err != noErr) {         fprintf(stderr, "failed to connect to Authorization Services\n");         return err;     }     // Check if the right is defined     err = AuthorizationRightGet(kTestActionRightName, NULL);     if (err != noErr) {         if (err == errAuthorizationDenied) {             // Create right in the policy database             err = AuthorizationRightSet(                       authRef,                       kTestActionRightName,                       CFSTR(kAuthorizationRuleAuthenticateAsSessionUser),                       CFSTR("You must be authorized to perform DoSomething."),                       NULL,                       NULL                   );             if (err != noErr) {                 fprintf(stderr, "failed to set up right\n");                 return err;             }         }         else {             // Give up             fprintf(stderr, "failed to check right definition (%ld)\n", err);             return err;         }     }     // Authorize right     authorization.name = kTestActionRightName;     err = AuthorizationCopyRights(authRef, &rights, NULL, flags, NULL);     if (err != noErr)         fprintf(stderr, "failed to acquire right (%s)\n", kTestActionRightName);     else         fprintf(stderr, "right acquired (%s)\n", kTestActionRightName);     // Free the memory associated with the authorization reference     AuthorizationFree(authRef, kAuthorizationFlagDefaults);     exit(0); } $ gcc -Wall -o testright testright.c -framework Security\         -framework CoreFoundation $ ./testright ... $ less /etc/authorization ... <key>com.osxbook.Test.DoSomething</key> <dict>     <key>default-prompt</key>     <dict>         <key></key>         <string>You must be authorized to perform DoSomething.</string>     </dict>     <key>rule</key>     <string>authenticate-session-user</string> </dict> ...

2.14.2.6. Miscellaneous Security-Related Features

Other Mac OS X security features readily available to end users, or otherwise controllable by them, include the following.

• Mac OS X provides a feature called FileVault, wherein an AES-encrypted disk image is used to hold the contents of a user's home directory. For example, if FileVault is enabled for an existing user amit, then amit's home directory/Users/amit/will contain a disk image file called amit.sparseimage. This file contains an HFS Plus volume and is visiblesay, from an administrator accountwhen amit is not logged in. Once amit logs in, the volume within the disk image is mounted on /Users/amit/, whereas the previous contents of /Users/amit/ (in particular, the image file itself) are moved to /Users/.amit/.

• Mac OS X provides secure file deletion through the Finder's Secure Empty Trash menu item and through the srm command-line program. The Disk Utility application (Disk Utility.app) allows disks and volumes to be securely erased using one of many schemes: write zeros over all data on disk (zero-out data), write data over the entire disk 7 times (7-pass erase), and write data over the entire disk 35 times (35-pass erase). Moreover, recovery of already deleted files can be made difficult by securely erasing existing free space on a volume.

• We earlier looked at encrypted virtual memory as a kernel feature. It can be enabled or disabled through the Security pane of the System Preferences application. At boot time, the operating system checks for the ENCRYPTSWAP shell variable to determine whether virtual memory should be encrypted. The variable's value is set to -YES- or -NO- in /etc/hostconfig depending on the setting selected in System Preferences.

2.14.3. System Administration

Mac OS X can be effectively administered through either graphical user interfaces or the command line. Let us look at some examples of using the command line to control Mac OS Xspecific aspects of system administration.

2.14.3.1. Interacting with the Security Framework

The security command provides access to the functionality in the Security framework (Security.framework). In particular, it can be used to access and manipulate certificates, keys, keychains, and password items, as shown in Figure 236.

Figure 236. Examining keychains using the security command

$ security list-keychains "/Users/amit/Library/Keychains/login.keychain"     "/Library/Keychains/System.keychain" $ security dump-keychain login.keychain ... keychain: "/Users/amit/Library/Keychains/login.keychain" class: "genp" attributes:     0x00000007 <blob>="AirPort Express"     0x00000008 <blob>=<NULL> ...

2.14.3.2. Interacting with Directory Services

The server version of Mac OS X uses the LDAP-based^[83] Open Directory software to provide directory and authentication services for Mac OS X, Unix, and Windows clients. A directory service is simply a central repository for storing and vending information about users, computers, printers, and other network resources in an organization. Application and system software can access such information for a variety of purposes: authenticating logins, locating user home directories, enforcing resource quotas, controlling accesses to file systems, and so on. Traditionally, Unix systems store such information in flat text files, such as those in the /etc directory. In fact, the Unix /etc directory could be seen as a primitive directory service. Other examples of directory services include Sun's Network Information Service (NIS)^[84] and Microsoft's Active Directory.^[85] The legacy directory service in Mac OS X Server is called NetInfo. Although no longer used for shared directories, NetInfo is still the directory service for the local directory domain on Mac OS Xthat is, for users and resources on the local system.

^[83] LDAP stands for Lightweight Directory Access Protocol. It is a widely deployed open standard.

^[84] An old name for NIS is Yellow Pages (yp). The successor to NIS is called NIS+. Recent versions of Solaris have deprecated NIS and NIS+ in favor of LDAP-based directory services.

^[85] Active Directory is LDAP-based as well.

The dscl command can be used for operating on data sources, which can be directory node names or hosts that are running directory services. Similarly, the niutil command utility can be used for operating on NetInfo domains. However, note that Open Directory includes a NetInfo plug-in that allows interoperation with NetInfo. Figure 237 shows examples of using dscl and niutil.

Figure 237. Interacting with Directory Services by using command-line tools

$ niutil -list . / # List directories in the path '/' in the local domain '/' 1        users 2        groups 3        machines 4        networks ... $ dscl /NetInfo/root -list / # List subdirectories of the path '/'                              # using the data source /Netinfo/root AFPUserAliases Aliases Groups Machines Networks ... # dscl sorts by directory names, niutil sorts by directory IDs $ dscl . -read /Users/amit # Read record for user amit ... NFSHomeDirectory: /Users/amit Password: ******** Picture: /Library/User Pictures/Nature/Lightning.tif PrimaryGroupID: 501 RealName: Amit Singh RecordName: amit ... $ niutil -read . /users/amit # Read record for user amit ... $ niutil -read . /users/uid=501 # Read record for user with UID 501 ... $ dscl . -passwd /Users/amit # Change amit's password ... $ dscl . -search /Users UserShell "/usr/bin/false" # Search for users with the specified shell nobody          UserShell = ("/usr/bin/false") daemon          UserShell = ("/usr/bin/false") unknown         UserShell = ("/usr/bin/false") ...

2.14.3.3. Managing System Configuration

The scutil command can be used to access and manipulate various configuration aspects of the local system. The System Configuration daemon (/usr/sbin/configd) stores relevant configuration data in a dynamic store that is accessible via scutil. It uses several configuration agentseach of which is a plug-in that handles a particular configuration management areato form an overall view of system configuration. The agents reside in /System/Library/SystemConfiguration/ as bundles. For example, the IPConfiguration agent is responsible for establishing (say, via DHCP) and maintaining IPv4 addresses.

Figure 238 shows an example of accessing the system configuration dynamic store using scutil.

Figure 238. Using the scutil command to access the System Configuration dynamic store

$ scutil > list subKey [0] = DirectoryService:PID subKey [1] = Plugin:IPConfiguration subKey [2] = Setup: subKey [3] = Setup:/ ... subKey [26] = State:/Network/Interface/en1/AirPort subKey [27] = State:/Network/Interface/en1/IPv4 ... > show State:/Network/Interface/en1/AirPort <dictionary> {   Power Status : 1   BSSID : <data> 0x00aabbccdd   Card Mode : 1   Link Status : 4   SSID : dummyssid } > show State:/Network/Interface/en1/IPv4 <dictionary> {   Addresses : <array> {     0 : 10.0.0.1   }   BroadcastAddresses : <array> {     0 : 10.0.0.255   }   SubnetMasks : <array> {     0 : 255.255.255.0   } }

2.14.4. The Auditing System

The Mac OS X auditing system consists of kernel support and a suite of user-space programs.^[86] The kernel records audit events to a log filean audit trail filebased on several types of criteria. A user-space daemonauditdlistens to trigger events from the kernel and control events from user programs (the audit command-line utility by default). Trigger events inform auditd if the current log file has become full or if the file system free space has fallen below a configured threshold; if so, auditd will attempt to rectify the situation. For example, it may attempt to rotate the log. In this sense, auditd is a log management daemon. Control events are used to instruct auditd to switch to a new log file, reread the configuration file, or terminate the auditing system.

^[86] In Mac OS X 10.4, user-space auditing programs and configuration files are provided by the Common Criteria Tools package, which is not installed by default.

Table 22 lists the key executables and configuration files in the auditing system.

Table 22. Auditing System Components

File/Directory	Description
/usr/sbin/auditd	Audit log management daemonreceives "trigger" messages from the kernel and "control" messages from the audit management utility
/usr/sbin/audit	Audit management utilityused to control the audit daemon by sending it control messages
/usr/sbin/auditreduce	Utility that selects records from the audit trail files based on the specified criteria and prints matching records in raw formeither to a file or to the standard output
/usr/sbin/praudit	Utility that prints selected records in human-readable format
/var/audit/	Directory for storing audit trail files
/etc/security/rc.audit	Script executed during system startup by the /etc/rc master script to start the audit daemon
/etc/security/audit_control	Default audit policy filecontains global audit parameters
/etc/security/audit_class	File containing descriptions of audit event classes
/etc/security/audit_event	File containing descriptions of audit events
/etc/security/audit_user	File specifying event classes that are to be audited on a per-user basis
/etc/security/audit_warn	Administrator-configurable script run when the audit daemon generates a warning

Auditing can be enabled or disabled by setting the AUDIT variable to -YES- or -NO-, respectively, in the /etc/hostconfig file. The variable can also be set to -FAILSTOP- or -FAILHALT-, both of which enable auditing with additional conditions. The former runs auditd with the -s argument, which specifies that individual processes will stop if the audit log becomes full and running the processes will result in loss of audit records. The latter runs auditd with the -h argument, which specifies that the system should halt in case of an auditing failure.

The kernel logs to only one audit trail file at a time. Trail filenames use a specific format: a string consisting of the file's creation time, followed by a period, followed by the termination time. The name of the active trail filethat is, the one that has not been terminated yetcontains the string not_terminated instead of the termination time. Both time substrings are constructed by using the %Y%m%d%H%M%S format specifier with the strftime() function.

The audit_control, audit_user, and audit_warn files are typically modified to configure the auditing system. Figure 239 shows the representative contents of an audit_control file.

Figure 239. An audit control file

# /etc/security/audit_control # Directory/directories where audit logs are stored # dir:/var/audit # Event classes that are to be audited system-wide for all users # (Per-user specifications are in /etc/security/audit_user) # # This is a comma-separated list of audit event classes, where each class # may have one of the following prefixes: # #     +  Record successful events #     -  Record failed events #     ^  Record both successful and failed events #     ^+ Do not record successful events #     ^- Do not record failed events # # The class specifiers are listed in audit_class(5) # Examples: # #     all All events #     ad  Administrative events #     cl  File close events #     fa  File attribute access events #     fc  File create events #     lo  Login/logout events # flags:lo,ad,-all,^-fa,^-fc,^-cl # Minimum free space required on the file system where audit logs are stored # When free space falls below this limit, a warning will be issued # minfree:20 # Event classes that are to be audited even when an action cannot be # attributed to a specific user # naflags:lo