SecureMac, Inc.

Mac OS X Security – Third lesson by Chevell@SecureMac.com

June 2, 2001

Macintosh OS X Security – Third Lesson

MAC OS X Now that we’ve covered the basics of computer security in general and an overview of Mac OS X security specifically, it is time to get a bit more in depth. Because some UNIX gurus and elite hackers now know Mac OS X better than most early-adopting Mac fans, caution needs to be taken above and beyond what has already been covered. This is because of the advanced capabilities of the new OS and the open source condition of many of the …

Mac OS X Security – Third lesson by Chevell@SecureMac.com

Macintosh OS X Security – Third Lesson

MAC OS X Now that we’ve covered the basics of computer security in general and an overview of Mac OS X security specifically, it is time to get a bit more in depth. Because some UNIX gurus and elite hackers now know Mac OS X better than most early-adopting Mac fans, caution needs to be taken above and beyond what has already been covered. This is because of the advanced capabilities of the new OS and the open source condition of many of the components within.

In general, user auditing, password protection and secure shell logging can keep a majority of systems safe from attack. High profile systems with many users or multiple guests can be a specific target by those who would be malicious. For these systems, a heightened level of security is required to ensure the integrity of data and overall stability of the system.

As mentioned in the previous installment, staying up to date with the latest bug reports, application versions and security advisories is key to ensuring a secure environment. Since that installment, Apple has released the 10.0.1 Update, which enables SSH, eliminating the risk from unsecured telnet sessions. Most users have already installed this update and moved on. Some however, have taken heed of warnings issued by those who have been using SSH for years. The version that Apple included in the updater has a well-known security exploit. This is easily fixed by downloading the latest version of OpenSSH, compiled and packaged for Mac OS X. This is a great example of how staying on top of the latest news is a critical part of server administration.

Security administration goes further than simply installing the latest versions of software and watching user accounts closely. For example, the root account, as mentioned previously, has absolute power over the system. We’ve been advised not to use the account and Apple has even made it quite difficult to do so. We can now unlock this account and even log into it locally or switch to it remotely. This behavior is dangerous for several reasons, but, as one reader pointed out, the root account might be better off not left alone.

Zach pointed out to me that the use of any admin account, including root, could be detrimental to the system. He suggested setting a known root password and then never using it. This may help the recovery process after a system hack, assuming the hacker forgot to reset root to an unknown variable. The root account is also less likely to be hacked if its used as little as possible.

Imagine, for a moment, that you are the admin for a small, multi-user, Mac OS X system. You’ve setup a few users, and you are the only admin. All the users are your friends and you trust them all completely. Somehow, through no one’s fault in particular, your admin account is compromised. From this account, the hacker can then use the sudo command to activate the root account and set his or her own password, giving free reign to any part of the OS.

This situation is much less likely to occur if the admin account was rarely used. The likelihood that the admin password would end up in the wrong hands is greatly decreased by creating a second �admin� account without administrative privileges. When, if ever, administrative rights are needed, the original admin account can be used. When within the GUI, any user, at any time, may install or modify preferences that require admin access simply by typing the admin password when asked. Therefore, a basic user account is rarely hindered by lack of admin access in a single user, local usage scenario.

A successful server administrator must also actively seek out possible security holes in any changes that he or she makes. A system, when first installed, is virtually unhackable. It’s when changes begin to take place that the exploits become available to hackers. One of the most common ways that a server admin can open up a security hole is through file permissions. Opening up files or directories for read, write or execute by users other than those set by default or those who own the files can greatly increase the chances of an exploit. The Mac OS X.org CLI Tutorial is a great place to learn about these permissions and their effects.

The best way to become an overnight success in the field of server administration is to learn as much as possible about how processes, server daemons, and user authentication methods in Mac OS X. This information is currently a bit lacking even from Apple. Instead, learn about Mac OS X Server 1.2, Free or OpenBSD, or even Linux in the general sense and apply the ideas to Mac OS X. Many of the same theories are in use in OSX with only slight variations in application.

An informed administrator is the most powerful weapon against hackers. It probably isn’t possible to know more than most of these minions, but it is possible to know enough to be dangerous- at least to them. Keeping up to date on the latest news, information and strategies will help ensure a secure environment.

Get the latest security news and deals