Previous Page | 1 2 3 4 5 6 | Next Page

Out Of The Box Security and Additional Hardening Measures

The out of the box secu­rity set­tings of OS X, in com­par­i­son to other pop­u­lar oper­at­ing sys­tems, can only be described as con­ser­v­a­tive. A secu­rity tech­nol­ogy brief from Apple explains the approach to secu­rity in OS X as “Secure from the start, easy to keep secure, and easy to make even more secure.” As adver­tised, the default instal­la­tion of OS X, with all rel­e­vant secu­rity updates applied is quite secure. There are sev­eral impor­tant fac­tors that play into this.

The supe­ruser of OS X, in tra­di­tion with other UNIX sys­tems, is a user called root. How­ever, in OS X, the root user plays some­what of a phan­tom role. Although it is present in all OS X sys­tems and plays a role behind the scenes, the account itself is dis­abled by default. Most users of OS X will never need to enable it or even know that it exists. This is a strik­ing depar­ture from sys­tems like Win­dows, whose default user is in effect, root.

In addi­tion to the root user, OS X has also inher­ited a fully func­tional multi­user oper­at­ing system. OS X is designed for use by mul­ti­ple people, each shar­ing their own Home Direc­tory, com­plete with appli­ca­tion pref­er­ences. All files and fold­ers in the system have built-​in per­mis­sions set­tings and each user’s Home Direc­tory is designed so that no one but that user and root has access to it. New user accounts in OS X are always set to ‘normal’ unless oth­er­wise spec­i­fied, mean­ing the account only has basic priv­i­leges by default. This fol­lows the secu­rity rule com­monly known as the “principle of least privileges.”

One impor­tant aspect in host secu­rity is turn­ing off all unnec­es­sary net­work ser­vices. In the past some oper­at­ing sys­tems turned on many ser­vices by default to ease ini­tial con­fig­u­ra­tions; this is now con­sid­ered bad prac­tice because for each ser­vice enabled, a new attack vector is instan­ti­ated. In Cor­po­rate Com­puter and Net­work Secu­rity, Ray­mond Panko com­ments that “security experts now agree that a firm should turn off all unnec­es­sary ser­vices because a large number of exploits take advan­tage of vul­ner­a­bil­i­ties in obscure and little used services…”(* Panko, Ray­mond R. Cor­po­rate Com­puter and Net­work Secu­rity. 228.*) OS X goes one step fur­ther by dis­abling most of these ser­vices by default.

In a default OS X instal­la­tion, only four net­work ser­vices are enabled by default: auto­mounter, syslog, sunrpc and Net­Info. These four ser­vices are essen­tial parts of the oper­at­ing system and cannot be turned off. Some of the impor­tant ser­vices included with OS X but dis­abled by default are SSH, FTP, File shar­ing over AFP and per­sonal web shar­ing. These ser­vices can be easily turned on and off through a GUI dia­logue in the System Pref­er­ences appli­ca­tion. By includ­ing these fea­tures but dis­abling them by default, Apple has taken a very impor­tant step that sac­ri­fices nei­ther secu­rity nor ease of use.

No matter how secure any system is at its release, there will be inevitably be vul­ner­a­bil­i­ties and bugs. The rea­son­able approach to coun­ter­act this is to pro­vide reg­u­lar soft­ware and secu­rity updates. Sim­i­lar to Win­dows, OS X also pro­vides a method for auto­matic updat­ing that is built in to the oper­at­ing system. The update appli­ca­tion, called Soft­ware Update, checks for updates weekly by default (cita­tion same as last link). In addi­tion to system-​related updates, Soft­ware Update also checks for updates to all other Apple soft­ware installed on the oper­at­ing system.

Lastly, OS X also includes a built-​in system for log­ging all impor­tant system related events. The logs can be easily viewed in the Con­sole appli­ca­tion or at the com­mand line inter­face for advanced users. OS X logs system events, crash reports and also all secu­rity related events, includ­ing any invo­ca­tions of sudo (cita­tion same as last link).

Despite the “secure from the start”, secu­rity motto for OS X, there are still some weak points in the default instal­la­tion of OS X. Most of these weak points can be easily reme­died, but they do require active inter­ven­tion by the user and usu­ally at least some knowl­edge of the fea­tures in general.

As pre­vi­ously men­tioned, OS X is designed to be a multi­user system and each newly cre­ated user is a normal user with­out admin­is­tra­tive priv­i­leges. This is true, with one notable excep­tion; upon installing OS X for the first time you are required to create a user account, which is actu­ally an admin­is­tra­tive account. After suc­cess­fully cre­at­ing the account the user is logged in to the system with­out any fur­ther notices regard­ing addi­tional users.

While the admin group in OS X is not quite the equiv­a­lent of the root user, it does have the abil­ity to esca­late priv­i­leges for short peri­ods of time in order to authen­ti­cate actions that would nor­mally require root access. An exam­ple of this is the UNIX sudo com­mand, which allows all users and groups listed in the sudo­ers file to per­form root-​level oper­a­tions on the system. In layman’s terms, this means they can do any­thing, includ­ing delet­ing the system.

The most unfor­tu­nate aspect of this is that the normal setup rou­tine in the OS X instal­la­tion does noth­ing to describe the secu­rity impli­ca­tions of this. There is no indi­ca­tion as to the fact that the user being cre­ated is an admin and more impor­tantly, no indi­ca­tion that this should not be the pri­mary user of the system. This is clearly a direct vio­la­tion of the “principle of least privileges” rule.

Moving past the unfor­tu­nate design deci­sions regard­ing this first user, it is a rel­a­tively pain­less process to add an addi­tional non-​admin user for every­day use. If just start­ing out with a fresh instal­la­tion, the user can simply pro­ceed to make an addi­tional non-​admin account and use that one reg­u­larly. The design of OS X allows for a normal user to authen­ti­cate system changes (i.e. net­work set­tings and appli­ca­tion instal­la­tions) using an admin­is­tra­tive account and pass­word. There is no need to actu­ally change accounts. Fur­ther­more, there is noth­ing spe­cial about the first user of an OS X system. The user can always at a later point in time create a new admin account and then deesca­late the priv­i­leges of the first account. This avoids the frus­trat­ing and time con­sum­ing oper­a­tion of having to change a user accounts.

Modern secu­rity sug­gests that no oper­at­ing system is com­plete with­out some sort of built-​in fire­wall. OS X has included a fire­wall with the system since OS X 10.2. The inter­face for the fire­wall is some­what prim­i­tive by design in an attempt to encour­age normal users to make use of it. FJ de Ker­madec elab­o­rates on this by stat­ing “some users may argue that the inter­face pro­vided by Apple does not allow a lot of fine-​tuning: this true, but is done on pur­pose to allow even new­com­ers to ben­e­fit from reli­able secu­rity set­tings, with­out having to worry too much about settings.” Up until the release of Leop­ard, the built in fire­wall GUI inter­face was based entirely on ser­vices. Users select which net­work ser­vices, such as per­sonal file shar­ing, remote login and printer shar­ing, they would like to allow or restrict (Mac OS X Secu­rity Con­fig­u­ra­tion For Ver­sion 10.4 or Later Second Edi­tion (PDF)). Behind the basic GUI inter­face of the OS X fire­wall is the ipfw com­mand line fire­wall tool. This allows a much more fine- grained cus­tomiza­tion for advanced OS X users.

While the sim­pli­fi­ca­tion of the GUI inter­face for the OS X fire­wall can arguably be better or worse for secu­rity, and even per­haps both, there are some addi­tional seri­ous short­com­ings. First and fore­most is that the fire­wall is not enabled by default on any ver­sion of OS X. Fur­ther­more, the inter­face to access it is buried deep in the System Pref­er­ences appli­ca­tion. This is a real prob­lem for most users; Ker­madec notes, “few Mac OS X users know that their oper­at­ing system of choice comes with a built-​in, time-​tested, indus­trial strength fire­wall that they can turn on by simply using the ‘Sharing’ pref­er­ences pane.” Look­ing past the issue of enabling the fire­wall, the tech­nol­ogy itself has a few holes.

It was not until OS X 10.4 that the fire­wall enabled any­thing more than TCP fil­ter­ing rules. Even in 10.4, UDP and ICMP fil­ter­ing is only avail­able through advanced con­fig­u­ra­tion of the fire­wall. Apple’s Bon­jour ser­vice also proves to be some­what prob­lem­atic as well. Bon­jour is Apple’s ver­sion of a local net­work dis­cov­ery pro­to­col for devices such as print­ers and com­put­ers and is known as mDNSRe­spon­der to the system. To enable it to work prop­erly, “mDNSResponder lis­tens by default on UDP port 5353.” This is also true regard­less of whether or not UDP has been dis­abled through the fire­wall. See: The Mac OS X Threat Land­scape: An Overview, pages 9-10(PDF) Any ser­vice that lis­tens by default on a port and cannot be dis­abled by the user is cer­tainly problematic.

One last miss­ing secu­rity detail to high­light involves the Soft­ware Update appli­ca­tion. The appli­ca­tion checks for system and secu­rity updates weekly by default. It can also be set to check for updates as fre­quently as daily and even down­load the updates auto­mat­i­cally in the back­ground. Baf­flingly, it is not pos­si­ble to auto­mat­i­cally install updates. In his review of OS X Tiger, Paul Thur­rott expounds upon this:

While you can check Soft­ware Update for new updates man­u­ally, you can also con­fig­ure it to check for updates on a reg­u­lar basis (say, daily) and down­load impor­tant updates in the back­ground while your work­ing [...]. How­ever, Soft­ware Update cannot be con­fig­ured to auto­mat­i­cally install secu­rity updates, which I find some­what confusing.

This con­fig­u­ra­tion may make sense in a large firm set­ting; there are other meth­ods with which IT pro­fes­sion­als can roll out the updates, allow­ing them to pick and choose which to apply and when. Unfor­tu­nately, for single users and small busi­nesses, this deci­sion seems to leave an unnec­es­sary burden on users to man­u­ally apply each update.

The most recent release of OS X, 10.5 (Leop­ard) touts many new secu­rity fea­tures. Some of the major new fea­tures include appli­ca­tion sand­box­ing, address space ran­dom­iza­tion, an appli­ca­tion based fire­wall and input man­ager restrictions.

Both appli­ca­tion sand­box­ing and address space ran­dom­iza­tion are impor­tant secu­rity addi­tions to any oper­at­ing system. Appli­ca­tion sand­box­ing, also called manda­tory access con­trols, pro­vides kernel level con­trol over what indi­vid­ual appli­ca­tions have access to and can do. See: A Roundup Of Leop­ard Secu­rity Fea­tures In the case of an exploit that might use a browser to arbi­trar­ily exe­cute code, a sandbox- type envi­ron­ment might pre­vent this.

Address space ran­dom­iza­tion goes a long ways towards pre­vent­ing buffer over­flow exploits. This fea­ture ran­dom­izes impor­tant address ref­er­ences in the system, making it harder for hack­ers to antic­i­pate where an over­flow might occur. It also makes it much more dif­fi­cult to write an exploit that will reli­ably work on a wide range of sys­tems, since each system is ran­dom­ized. See: The Mac OS X Threat Land­scape: An Overview, pages 9-10(PDF).

While acknowl­edg­ing that each of these fea­tures are impor­tant, some secu­rity experts have lev­eled crit­i­cism on their imple­men­ta­tion. In the case of sand­box­ing, the default pro­files don’t seem to actu­ally stop any of the most obvi­ous threats. Impor­tant appli­ca­tions that have reg­u­lar access to remote net­works, such as Mail, Safari and iChat aren’t actu­ally sand­boxed. Apple’s cur­rent imple­men­ta­tion and doc­u­men­ta­tion of the fea­ture also make it dif­fi­cult for respon­si­ble third-​party devel­op­ers to use it. Leopard’s imple­men­ta­tion of address space ran­dom­iza­tion has been crit­i­cized for not being random enough. See: A Roundup Of Leop­ard Secu­rity Fea­tures.

The new appli­ca­tion based fire­wall in Leop­ard switches from the pre­vi­ous ser­vice based model to an appli­ca­tion based one. While this isn’t nec­es­sar­ily a bad thing, it also hasn’t made any inroads towards a more robust and con­fig­urable fire­wall. In fact, it seems to have taken a step back­ward. The fire­wall allows three basic set­tings: allow all incom­ing con­nec­tions, block all incom­ing con­nec­tions and set access for spe­cific ser­vices and appli­ca­tions. Clearly the first two options are not prac­ti­cal, so we are left with the third option, which seems to have a rather odd and con­fus­ing inter­face as Rich Mogull explains in “Leopard Fire­wall Takes One Step For­ward, Three Steps Back”:

The first prob­lem [...] is that it’s dif­fi­cult to tell what the Set Access option does. It starts the new application-​level fire­wall and lists in the Shar­ing pane any ser­vices you’ve opened, but it doesn’t indi­cate if they are allowed or blocked. There’s also no option for you to add your own open ser­vices or ports any­more. Instead, you can add or remove indi­vid­ual appli­ca­tions, but not net­work ser­vices. Stealth mode is still avail­able in the Advanced set­tings, but the UDP block­ing, useful to stop port scan­ning and some other attacks, is gone.

Leop­ard has also changed the inter­nal imple­men­ta­tion of the fire­wall, replac­ing ipfw with an Apple devel­oped fire­wall, which is less well known and pos­si­bly harder to do advanced con­fig­u­ra­tions in. Most impor­tantly, Apple still has not changed the default fire­wall set­ting to be on rather than off.

The restric­tions on input man­agers in Leop­ard are an impor­tant step in clos­ing what was pre­vi­ously a major secu­rity risk in OS X. Secu­rity expert Thomas Ptacek describes input man­agers:

Input man­agers are ter­ri­fy­ing. They’re arbi­trary blobs of code that get injected into almost every Mac appli­ca­tion. They are a “UI exten­sion interface” in the same way that Back Ori­fice 2k is a “remote system admin­is­tra­tion facility”.

Leop­ard puts seri­ous restric­tions on what input man­agers can do, effec­tively clos­ing this secu­rity hole.

The new secu­rity fea­tures intro­duced in Leop­ard have a range in sig­nif­i­cance and qual­ity of imple­men­ta­tion. Con­sid­er­ing that 10.5 is only a few months old, it is pos­si­ble that they will be adjusted in future releases or updates.

The Mac OS X oper­at­ing system does clearly demon­strate good out-​of-​the-​box secu­rity, with only a few glar­ing weak­nesses. For­tu­nately there are sev­eral easy steps that users can take to harden OS X. First and fore­most, users should make sure to take the extra step at instal­la­tion time to make an addi­tional non-​administrative account for every day use. Users can also choose from sev­eral other options via the Secu­rity panel in System Pref­er­ences to fur­ther harden the system. Users can dis­able auto­matic login, enable auto­matic logout, require a pass­word to wake the com­puter from sleep or screen saver and require a pass­word to unlock each secure system pref­er­ence. The fire­wall can also be easily enabled and users can refrain from enabling unnec­es­sary net­work ser­vices. Installing system and secu­rity updates does require active user par­tic­i­pa­tion, but is not an undo burden.

Other impor­tant, but more com­plex, options that the secu­rity panel pro­vides are the options to use secure vir­tual memory and Fil­e­Vault encryp­tion. Choos­ing to use secure vir­tual memory allows the system to encrypt the memory’s swap file, which can con­tain con­fi­den­tial data. While this is easy to imple­ment, it is unlikely that most users under­stand what this does. Fil­e­Vault is Apple’s only imple­men­ta­tion of file encryp­tion for user data and can be easily enabled; how­ever because of some seri­ous short­com­ings in the imple­men­ta­tion and the dras­tic con­se­quences of losing a decryp­tion key, most pro­fes­sion­als do not nec­es­sar­ily rec­om­mend this par­tic­u­lar option.

Taking these few simple steps goes a long ways towards clos­ing any secu­rity holes in the default OS X instal­la­tion. While clearly not all attacks will be avoided using these meth­ods, they do cut off many attack vec­tors. A con­sid­er­able advan­tage of the approach taken with OS X, com­bin­ing secure defaults and ease of use, is that it presents secu­rity in a way that is acces­si­ble to normal users. OS X makes imple­ment­ing many fun­da­men­tal secu­rity prac­tices quite trivial.

Previous Page | 1 2 3 4 5 6 | Next Page