- Concerns About Physical Access
- Dual Booting and the Classic Environment
- Staying Current with Mac OS X
- User Accounts and Access Control
- Filesystem Encryption
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
User Accounts and Access Control
One of the driving principles of information security is the idea of Least Privilege. Least Privilege is the concept that an entity should be given only the fewest possible rights to perform its required activity and no more. For instance, if a user only needs to surf the Internet, he does not need the capability to change the system's IP address or add new users. By giving a user more access than he requires, you are opening the door to, at the very least, system instability and possibly security compromises. Unfortunately, most modern operating systems were not designed from the ground up to adhere to Least Privilege. Usability and extensibility won the day. Locking down users to a small subset of commands is a difficult job. Thinking about what your users need to accomplish and being diligent with systems configuration will drive up the security of your systems.
When Mac OS X is first installed on a host, a user is created with administrator privileges. This user has a great deal of control of the workstation, either directly through the various System Preferences panes or through other mechanisms such as sudo. Mac OS X attempts to limit the direct access this administrative user has by requiring an administrative password be supplied when an especially sensitive activity is performed. For example, when installing a third-party application that needs to modify your network stack, Mac OS X will launch an authentication screen to verify the activity. When launching commands through the Terminal program sudo, you are prompted for a password as well.
However, there are still a great number of activities that an admin user can perform that you may not want to allow everyone to do. Mac OS X comes with a robust user creation utility that allows you to have a reasonable amount of control over what users can and cannot do. If someone other than yourself will use your host, for example, a coworker or relative, it is advisable to create a user account specifically for that person which grants only the access they require.
Role Accounts
A role account is an account that multiple people use to gain access to a host. Role accounts are common in an office environment where a group of individuals require the same type of access. For example, everyone in finance may use the finance account to connect to an ftp server. Although this simplifies account management, it makes tracking illicit use very difficult. Every person accessing a system should have his or her own unique account. This provides a more complete audit trail for you to examine when something bad happens to the machine.
The Users tab in the Accounts System Preferences pane controls all user accounts on the system. Adding a new user is as simple as clicking New User and filling in all the required fields (see Figure 3.8). The Name field is what is commonly known in the UNIX world as the GECOS field. This should contain the user's full name and any relevant contact information. The Short Name field corresponds to the UNIX username. When filling in the password field, be sure to use a strong password. A strong password is not guessable and should contain a combination of letters, numbers, and special characters. Be sure the user changes her password when she first logs on to the host.
)
Figure
3.8 Adding a new user.
Leave the Password Hint field blank. As mentioned before this will be of great help to an attacker and should be disabled for the login screen. If need be, give the user administration privileges, but only do so if absolutely required. Also, you can allow the user to log in from a Windows host via SMB. This enables SMB access for the entire host and grants that user access to his or her files on the system. Again, only grant this access if it is required for your network. For more information on SMB and other network services, see Chapter 6, "Internet Services."
After the user has been added to the system you can further limit his access by clicking Capabilities in the Accounts pane. This allows for fine-grained control over what the user can and cannot do on the host. You can control whether the user can modify system settings, burn CDs, or even launch certain programs. Note that the Capabilities button is not available if the new user has administrator privileges. There is an option to enable the Simple Finder for the user. Simple Finder allows you to limit what applications a user can see. By selecting applications in the Applications list view, Simple Finder will only display the allowed applications. Also, Simple Finder can only open documents containing the users Documents folder in their Home. The Simple Finder cannot open ordinary folders.
The underlying mechanism that controls user accounts is not the standard UNIX /etc/password architecture. NetInfo is a distributed user management system that is employed by Mac OS X for authentication and authorization issues. When making changes to a user, you are really making the changes to the NetInfo database. For more information on NetInfo see NetInfo in Chapter 10, "Directory Services." The UNIX /etc/password construct is used by Mac OS X only in the event of booting to single user mode.
Limiting Access Is Hard to Do
Restricting access to a subset of programs is not always bulletproof. Remember Bruce's mischievous coworkers who were constantly breaking into each other's workstations? Well, they were also finding ways to break through various restrictions on their user accounts imposed on them based on Least Privilege. Through the sudo tool they were granted rights to the UNIX editor vi so they could edit various sensitive system files when needed. However, vi could be used to view files they were not supposed to view. It was also able to launch other programs from within itself. So using the higher privilege level of the vi process, they could run other programs which were not explicitly allowed to them under sudo.
The problem was due to transitivity of trust from sudo to vi to other external programs. By giving them explicit rights to use vi, sudo was actually giving them rights to all the programs on the host. Luckily, rather than be malicious about the excess trust, they used it as a tool to learn more about locking down user accounts. One of them would modify sudo to further limit access while still allowing everyone to do their jobs and the rest of them would try to break out of the little "jail" that was created. It taught them the good and bad about Least Privilege and trying to enforce it.
Remember, just because a user does not have explicit access to a program through his account does not mean he will not find a way to access it.