Lesson 12. Mac OS X Security Overview

Time	This lesson takes approximately 1 hour to complete.
Goals	Understand the purpose of the components of the Mac OS X security architecture Learn the Apple authorization philosophy Identify the components of the security process Produce an IT security policy document

Security has never been a more important consideration when selecting a computer platform. Whether you’re a home user with a broadband Internet connection, a professional with a mobile computer, or an IT manager with thousands of networked systems, you must safeguard the confidentiality of information and the integrity of your computers.

In Part 2: “Security Administration,” you’ll learn how to do just that. The lessons in this section will teach how to use the Apple security strategy, implementing the options that provide the best balance between protection and functionality. Beginning with this lesson on the underlying Common Data Security Architecture (CDSA), you will gain an understanding of the technical foundation of Mac OS X security features. Yet just as important is understanding and implementing appropriate security policies for your environment. This begins with a thorough risk analysis of your computers and data, assessing the likelihood and potential severity of individual threats and weighing them against the business costs and loss of productivity often introduced by highly protected computer systems.

With Mac OS X, Apple has implemented a security strategy that is central to the design of the operating system, ensuring that your Mac is safe and secure. Throughout the next ten lessons, you will learn all about that strategy, including the following elements:

• Open-source foundation: Using open-source methodology makes Mac OS X a more robust, secure operating system, as its core components have been subjected to peer review for decades. Problems can be immediately identified and fixed by Apple and the larger open-source community.

• Secure default settings: When you take a Mac out of the box, it is already configured in the most secure form—so you don’t have to be a security expert to set it up. These secure settings make it very difficult for malicious software to infect your system.

• Modern security architecture: Mac OS X includes state-of-the-art, standards-based technologies that enable Apple and third-party developers to build secure software for the Mac. These technologies support all aspects of system, data, and networking security required by today’s applications.

• Innovative security applications: Mac OS X includes features that take the worry out of using a computer: FileVault protects your documents using strong encryption, an integrated VPN client gives you secure access to networks over the Internet, and a powerful firewall secures your home network.

• Rapid response: Because the security of your system is so important, Apple responds rapidly to provide patches and updates. Apple works with worldwide partners, including the Computer Emergency Response Team (CERT), to notify users of any potential threats. Should vulnerabilities be discovered, the built-in Software Update tool automatically notifies users of security updates, which are made available for easy download and installation.

Understanding Common Data Security Architecture

Mac OS X security services are built on CDSA, with support for cryptography, certificate management, trust policy management, and key recovery. This layered security infrastructure makes it easy for Apple and Mac OS X developers to integrate leading-edge security features, such as authentication and encryption, into their applications.

By using CDSA, Apple takes advantage of a well proven, flexible, extensible security architecture. That is in keeping with the open-source nature of the Darwin layer of Mac OS X. Apple then builds user-friendly front-end applications, such as Disk Utility and Keychain Access, that help the average user take advantage of the power of this cryptographic services toolkit. Anything in Mac OS X that is doing cryptography is doing it through the CDSA application programming interfaces (APIs).

CDSA was originally developed by Intel, in cooperation with other leading companies including Hewlett-Packard, IBM, JP Morgan, Motorola, Netscape, Trusted Information Systems, and Shell Companies. Apple has also been a major contributor to the standard and has greatly extended the functionality of CDSA.

Add-in Modules

The CDSA architecture uses plug-ins to allow additional services to be supported. The different types of plug-ins are Cryptographic Service Providers (CSPs), Data Library Modules (DLs), Certificate Library Modules (CLs), and Trust Policy Modules. To support Pretty Good Privacy (PGP) certificates, for example, a developer could write CL and TP Modules that know how to parse PGP certificates and the trust policies associated with them. The keychain is implemented as a combination CSP/DL. These are described in more detail in the CDSA reference.

Layered Services

Layered Services is the Apple terminology for convenience APIs built on top of the basic CDSA functionality. For example, most developers may have to save a password securely, and can do this through two APIs. Direct calls to CDSA might require thousands of lines of code. Apple chose to make security easy for third-party (and internal) developers as well, since most are not security experts. In addition, this gives the user a common experience.

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.

Developing an IT Security Risk Analysis

Security professionals recognize that the more secure a system is, the less functional it is likely to be. Security features often get in the way of quickly getting a task done, and strict policies can often have the opposite detrimental effect of causing users to seek ways to bypass security.

Security is an ongoing process, not an end product. Just like your immune system, your security process can never rest completely. Although you may face periods when new attacks are of little threat, you can never relax completely because you cannot predict when the next assault will occur or when a user will accidentally open up a previously closed hole.

The security process consists of the following steps:

1. Analyze your risks.

Define how vulnerable your system is to attacks by assessing the threat level and the user’s security skills.

2. Assess risk versus cost.

Security is a compromise between an acceptable level of security and its associated cost. More security translates into more cost and vice versa.

3. Establish policies.

Once you have gathered the necessary information in the previous two steps, write a security policy. This will be a balancing act. The most convenient access will often be the least secure. A large part of this effort will be defining the various levels of access that you want to allow and which users should be permitted into each level.

Another large part of this effort will be user education. You’ll have to develop a strategy for teaching users what they can do, what they can’t do, and why certain things are not permitted. (Getting higher-level management backing on these issues is generally helpful.)

Also important in the balance between security and convenience is your own convenience. You need to ensure that you are not making system administration so difficult that you are loathe to undertake the necessary tasks.

4. Implement solutions.

Once policies are in place, the next step is to implement them. Set up the servers, firewalls, and user accounts. Get the users on your network using the servers.

5. Monitor the network.

Security is an ongoing process. You must monitor your network constantly to ensure that your policies are effective and that someone hasn’t inadvertently (or even deliberately) breached your security.

6. Formulate a response.

You must develop a plan of action in advance for responding to a breach of security, a lack of conformance to policies and guidelines, or a change in user needs (for example, your company grows from 15 users to 200). You might have to repeat the entire cycle or make implementation changes and go back to monitoring.

The full cycle doesn’t need to be completed each time you have a problem, but you should evaluate the full security picture with the full cycle in mind.

Assessing Threat Level

The first step in the problem space of the security process is to define vulnerabilities. To do so, you must assess threat level and user skills, which help determine the security needs of your organization.

The threat that has been popularized by mainstream media is that of an outside attacker accessing private information using a network connection. This is perhaps the least of the threats facing you in terms of security from the client side.

A more insidious attack is what is known as social engineering, which relies on people giving out information that they shouldn’t. Someone may call a user claiming to be from the help desk in your organization and saying that they need to reset passwords on a system.

A more mundane attack is simple physical theft. In addition to the loss of equipment, you and your users face significant downtime while you replace equipment and figure out how to replace lost data. Even worse is a case where confidential data falls into the hands of your competitors.

An attacker may take advantage of multiple avenues. For instance, an attacker may use social engineering to discover a password, then steal a portable computer or security token to gain access to information.

Other forms of attack are viruses and Trojan horses. These pieces of code are the subtlest of the threats, infecting mail, hard drives, and networks. The effect of these attacks can range from inconvenient to devastating.

Perhaps the most dangerous and common threat comes from insiders who already have access to your information. Keeping this threat under control is beyond the scope of this book, but the key to lessening it is careful use of permissions.

Also when assessing threat level, try to assess how determined an attacker might be. For example, if you have a high-profile website that provides access to classified information that is sought by adversaries, it is highly likely that an attacker will try every possible way to get to the information, resulting in a high threat level.

Defining User Skills and Needs

Assess who needs to use a particular resource. What will users do to circumvent the security if it is too inconvenient? Examples of other issues to consider are that users may:

• Not use the service at all, which wastes money and time

• Not log out of the system, so password policy may be moot

• Leave passwords out in plain view

• Copy files to insecure areas

As mentioned, security is a compromise between how much risk you’re willing to take and how much expense you’re willing to incur. To assess risk versus cost, you must:

• Consider examples of compromise based on your experience.

• Assess user needs to help you determine how many of them you should address to maintain an appropriate level of security and the associated cost. Following are some examples:

• Users access the network from outside the firewall using VPN.

• Users can take their computers, which might contain sensitive information, with them wherever they go.

• Users can share computers with other users.

• Assess organizational needs. Like user needs, an organization’s computing and security needs help you determine where to draw the line between risk and cost. Following are some examples of organizational needs that affect the balance between security and cost:

• Back up computers daily.

• Monitor logs daily.

• Check computers for viruses on a regular basis.

• Perform regular security audits to evaluate the current state of security in your organization and determine how best to improve it.

Establishing Policies

When establishing policies, your challenge is to balance convenient user access to services with organizational security needs. An absolutely secure computer is one that is turned off, unplugged, and locked in a bank vault, but it is not very convenient. A computer placed in a public library with no individual user accounts is convenient for whomever comes into the library, but it is not very secure.

Providing a service always opens a potential breach in security. Think of a computer as a blank wall—every service is an additional gate through the wall. Even if the gate is well protected, it’s still not as strong as a solid section of the wall.

Depending on the level of threat that your installation faces and the sophistication of your users, you will need to create a security policy that can keep your systems safe while still allowing for sufficient access.

Remember that convenience also includes the ease of system administration tasks. If you make system administration procedures too burdensome, someone will take a shortcut at some point that will potentially compromise security.

Keep in mind the phrase “obscurity is not security.” You cannot and should not rely solely on keeping the configuration of your computer systems secret. Apart from the fact that there are many techniques available to probe your systems, some of the greatest threats to security come from colleagues who must know your systems because of job function and responsibility.

Documenting Policies

One of the most important things you can do is write down your security policy. This creates clear expectations for users, system administrators, and management. The policy should be written plainly, avoiding jargon. Following are some examples of the information it should contain:

• Allowable uses

• Resource access policy and limits

• Monitoring policy

• Anticipated threats and relative risks

• Implemented defenses against anticipated threats

• Best practices

• Escalation procedures

• Checklist for follow-up audit after an exploit

In addition, you should document threats that you have examined but consider of such low probability that they are not worth defending against, threats that are too costly to defend against, or threats that are possible but require the cooperation of other agencies, such as your Internet service provider, to develop a proper defense.

Writing down this information serves two very important purposes:

• You are forced to be clear and consistent with your thinking about security.

• Your written policy is an invaluable tool when it comes to the hardest part of security—educating your users.

Implementing Solutions: Creating a Secure System

Once you have defined policies, you move from the problem space to the solution space. This is where you implement policies through system architecture and design:

• Configure hardware: Set up hardware firewalls, servers, and computers to comply with the policies you have defined for your organization. This includes setting firmware passwords and physical security of equipment.

• Configure software: Server software, firewalls, and user accounts must be configured for security. The default configuration for Mac OS X leaves services off; an administrator must enable them. This means that at the beginning, there are no known holes in the Mac OS X security posture. Opening a hole requires an action by someone who should be knowledgeable about the operating system.

In addition, unlike older versions of Mac OS, Mac OS X is a true UNIX-based multiuser system. This means that access privileges are always enforced and cannot be bypassed except by the root user. It also means that, unlike AppleShare IP, the access privileges are available at the file level as well as the folder level, which enables you to configure privileges to allow a finer degree of access control.

• Define processes: Users and administrators need processes to follow when using computing resources. For example, you can define a process that administrators follow to report and respond to a breach of security.

Monitoring the Network

After implementing the solutions, you need to monitor computers and network activity in your organization to detect any attempt or actual breach of security (inadvertent or deliberate).

Examples of monitoring include:

• Using Console or Terminal to monitor logs

• Using virus-detection software to check systems for viruses

• Using packet sniffers such as tcpdump and Ethereal to monitor network traffic

Formulating a Security-Breach Response

When monitoring computers and network activity, you might detect or be alerted to an actual or attempted breach of security. You need to formulate an action plan that will enable you to respond to the potential threat based on the processes that you have in place.

The work involved in the formulation of the response will vary with the nature of the alert. If the alert is minor, you may not need to adjust your policies, but rather tighten your implementation of the policies or solutions and enter the monitoring phase again. If the alert is major, your threat level may have increased enough to warrant redefining vulnerabilities and starting the security process again from the beginning. In all cases, the alert should be documented and a follow-up audit should take place as part of the monitoring process to ensure that the response succeeded in addressing the issue.

In reality, formulation can lead you back to any point in the security process, keeping the process flowing and dynamic. This is good, as security is an ongoing and ever-changing challenge. There will always be attackers pushing the security envelope. The key to keeping them at bay is keeping your security process active and flexible.

What You’ve Learned

• Security is a process that should be continually reviewed.

• Organizations should consider the tradeoff between security and convenience when designing a security policy.

• User education is critical for a secure environment.

• Security audits enable you to monitor security environments in order to revise security policies as needed.

References

URLs

The Open Group, “Common Security: CDSA and CSSM, Version 2”: www.opengroup.org/publications/catalog/c914.htm

Lesson Review

1. Mac OS X security services are built on what architecture?

2. What are the three user types in Mac OS X?

3. What is the single sign-on architecture used by Mac OS X?

Answers

1. Common Data Security Architecture (CDSA)

2. Standard user, administrative user, and system administrator (root)

3. Kerberos