December 14, 2005
(Computerworld)
In my last look at Macintosh security, I wrote about the importance of configuring individual workstations to make their local resources and data more secure (see "To secure a Mac workstation, remember the users"). In this installment, I offer a look at additional ways to tighten security on workstations, from disabling peer-to-peer sharing to limiting SSH access and securing local NetInfo data.
Let's jump right in.
Concerns About Root-Access (SUID) Applications
Disabling root and securing sudo access (sudo is short for super-user do) will keep most users from gaining root access, but there is also the suid-root feature that is used by some applications. Suid (set user ID) allows an application to be designed so that it can run with permissions beyond that of the user who launched it, generally as root. The application itself may not run as root, but some processes that it requires may.
In itself, suid is not a bad thing. Many diagnostic tools (both command line and GUI) make use of it to function without requiring users to act as root. For some of them, such as Disk Utility, Classic OS operation or several installers, it makes sense that they would need or use suid. The problem is that a clever user with enough Unix development knowledge could turn this feature into a way to gain root access.
If possible, delete the applications or tools that use suid from a workstation. Where that isn't possible or would lead to problems with functionality or troubleshooting, limit access to them. You can do this using managed preferences, by setting permissions on the applications themselves, or by placing them collectively in a folder and securing access to that folder using permissions. You can find suid using the following Unix command:
find / -perm -4000 -user 0
For GUI tools, you will see the suid components listed within each application as part the .app directory:
/Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy
Limit Access to Cron
Cron can be used for attacking workstations or servers, either directly or through a virus or script. Cron can be set to perform any scriptable action, meaning if someone gains access to a local user account with any level of access, he can cause the Mac to perform some task at a later date (possibly on a repeating basis). This can actually mask a serious intrusion because you may not notice that the commands have been added.
On Mac OS X Server, this is a reason to periodically check existing crontabs for anything new or unusual. Since you typically won't want to do this on every workstation (though you should if you suspect a workstation has been compromised), you might want to consider limiting access to cron. You can do this by creating a file named "allow" in the /var/cron directory, listing the short names of users (one per line) who are allowed access to the cron utility.
Disable Peer-to-Peer Sharing
This probably goes without saying, but do not enable any peer-to-peer file-sharing services (AFP, SMB, etc.) on workstations, and do not give users access to the Sharing pane in System Preferences (or the File Sharing control panel in Mac OS 8 and 9). The only sharing methods you might want to allow are Remote Login (SSH) and Apple Remote Desktop, if they are actively used or needed.
Limit SSH Access
By default, Mac OS X allows all users of a workstation to connect using SSH (assuming that SSH is enabled). This opens the workstation to more avenues of attack, particularly since most users will not use SSH to connect to a workstation. This isn't opening security holes in just that one workstation, either. You can port other services (such as file services) through an SSH tunnel using only the SSH network port, meaning SSH can effectively open up holes in your firewall -- and allow someone access to other resources within your network.
You can limit SSH access in two important ways: First, you can restrict the users who are given access to a workstation using SSH. You can do this by editing the sshd_config file located in the Unix /etc directory. Adding a line that begins with AllowUsers will allow SSH access only to those users whose short names are listed after it. You can also limit the IP addresses of computers users may connect from by adding the @ symbol and IP address after a user's name -- or you can allow a user to connect from an entire address range by entering a base IP address and subnet mask. An example is shown below:
AllowUsers ryanf karent@192.168.0.12 michaelj@192.168.0.0/8
You can also restrict specific users and allow all others by creating a DenyUsers line with the same syntax. This is less effective, however, because it requires you to know who to specifically deny access to and/or where they might connect from. You can also disallow SSH login as root by adding a line that says:
PermitRootLogin no
Beyond user access, you can control the version of the SSH protocol that can be used for connections. Mac OS X supports both Versions 1 and 2 and, by default, accepts connections from both. SSH Protocol 1 is significantly less secure than Protocol 2. You can require Version 2 by removing the #Protocol 2,1 line in the sshd_config file and replacing it with Protocol 2.
Restrict Apple Remote Desktop
When using Apple Remote Desktop (ARD), be sure to use the most restrictive user settings possible. In particular, take care when assigning permissions allowing users to change settings, delete and replace items, copy items, and control permissions to local accounts. You can and should create limitations on what capabilities workers have on a workstation. This limits access should their accounts be compromised or if local ARD-enabled account usernames and passwords are compromised. Also, don't make local administrator accounts into remote desktop user accounts because if these accounts are compromised, so is complete access to the workstation.
Likewise avoid enabling VNC server support if you enable ARD access to a workstation. This grants users control access to a workstation using only a password, making it far less secure than ARD, which relies on the local user account configurations as well as a user's access to the ARD application. And with the Remote Desktop application, remember to secure access to it on workstations that will be configured as administrator computers.
Limited Local Users,/b>
The fewer local users you create on a workstation, the more secure the workstation will be. Beyond limiting the number of users, you should limit the capabilities of all users and use permissions to disallow local users access to any files, operating system components and applications that they do no explicitly need. You should limit the number of administrative users on each workstation to a single user (the one created during Mac OS X installation). And for further security, you may want to use a nongeneric name like "administrator" or "admin" for this user, therefore requiring both the username and password to be known in order to gain access to it. And don't create guest users or generic user accounts because they create gaping security holes and are hard to track should they be used for security breaches. Also do not create users with empty (blank) passwords. Make certain that all local user accounts have passwords that are difficult to guess, are at least eight characters and include letters, numbers and punctuation characters.
Disable Mac OS 9 Access or Use Mac Manager
As I've said before, the classic Mac OS was not designed with network use or security in mind. When a workstation is started from a standard classic Mac OS installation, there are no permissions enforced by the operating system on any files or folders. A user can access any file on the hard drive. Mac Manager allows you to enforce permissions and user access restrictions on a workstation. If you are using classic Mac OS you should use Mac Manager (or at least Mac OS 9's Multiple Users feature, which is not as secure as Mac Manager).
If you do need to provide classic Mac OS tools, consider using the Mac OS X Classic environment. If you do use Classic, make sure to restrict user access to the Startup Disk System Preferences pane to prevent them from rebooting into Mac OS 9 because Classic is not compatible with Mac Manager or Multiple Users. A further way to secure the Classic environment is to use Shadow Classic, another excellent tool from Bombich Software, which allows you to configure the Classic environment to start from a disk image containing Mac OS 9 rather than from an actual Mac OS 9 installation, giving users access to Classic but not to a bootable Mac OS 9 disk.
Disallow Access to Any Workstation-Related System Preferences
There are several system preferences that affect the local workstation rather than the user environment (for a local or network user). You should restrict user access to these preference panes either by using Mac OS X Server managed preferences (for network user accounts) or limitations tab in the Accounts pane of System Preferences (for local users). In particular, you should restrict access to the following: Print and Fax, Accounts, Network, Sharing, Software Update, Startup Disk and Energy Saver. You may also want to restrict access to CDs, DVDs, displays, sound and Classic.
Secure Local NetInfo Data
A user with NetInfo experience can gain access to local user and system data through NetInfo files stored on a workstation's hard drive. Therefore, you should ensure that the permissions for the following files and folders limit access to them:
/var/backups
/var/db/netinfo
/private/var/backups/local.nidump
Use a Restricted Applications Folder
I alluded to this when talking about applications that make use of the suid feature. You should limit access for applications that users do not need access to, particularly those that could provide sensitive information or access to workstation or network configurations. You can do this using managed preferences (for network users) or the limitations tab of the Accounts pane in System Preferences (for local users). You can also do this by placing the applications in a folder that is restricted using file permissions. By doing that, you can even make the folder invisible to users who should not have access to it. Or you can take both approaches for added security. Some specific applications that you should consider restricting access to include the Terminal, NetInfo Manager, Directory Access, Disk Utility, Remote Desktop and the Mac OS X Installer.
Avoid Storing Files on Workstations,/b>
This has advantages beyond security, but by convincing users to store sensitive files on share points rather than a workstation's hard drive, you can secure access to those files more effectively. It may take some time to convince users to do, and it may not be appropriate in all cases, but it will enable greater file security. It will also enable you to easily back up those files and allow users access to them in the case of other problems with the workstation.
Ryan Faas is a network administrator and offers consulting services specializing in Mac and cross-platform network solutions for small businesses and education institutions. He is co-author of Troubleshooting, Maintaining and Repairing Macs (Osborne/McGraw-Hill, 2000) and of the forthcoming Essential Mac OS X Server Administration (O'Reilly, 2005). He can be reached at ryan_faas@yahoo.com.