IN THIS CHAPTER
Adding a New User
Using the NetInfo Database to Customize a User
Sane User Account Management
Skeleton User Accounts
Command-Line Administration Tools
Restricting User Capabilities
Users are people, and as Chapter 3, "People Problems: Users, Intruders, and the World Around Them," noted, people are your overall largest security problem. So it's important that you know and practice good system administration principles when creating and managing the user population on your computers. The choices you make when configuring the users on your machines will define their normal abilities. It won't prevent them from trying to extend those abilities outside what you intended, but your choices will affect their capabilities and range of action there, as well.
When configuring users, keep in mind the types of security issues and vulnerabilities that we've discussed through the previous six chapters, and how the options you have in user configuration can affect the capabilities of a user who is determined to cause mischief. Likewise consider the effect on their capacity to unintentionally cause damage through these routes, either to themselves or to others.
This chapter covers typical user configuration administrative options, as well as how to partially automate some parts of the process. If you're going to be in a position where you need to manage a large collection of users, pay close attention to the automation parts ; they will enable you to more easily keep your user creation process and configured options standardized, and will provide you with ways to make configurations that are outside of what Apple's Accounts system preferences pane can create.
In the end, the most secure user is the one you don't create, but that user has no utility. The instant you begin to give users the power to do things with your system, you begin to give them the power to do things that you don't want, and that will compromise your security to some extent. Where the balance is between nonusers with no capabilities and full administrative users who can su to root will depend on your needs and those of your users.
BUILDING USER/ADMINISTRATOR TRUST
We strongly recommend that you limit your users' capabilities to at least some extent; giving every user root access is a recipe for sure and swift disaster. On the other hand, we also strongly recommend against unnecessarily limiting your users' privileges.
Too many administrators place limits on their users not because of any increase in security that those limits provide, but out of some twisted desire to prepunish users for potential transgressions, in the hope that this will cow them into more quiescent obedience to the rules. This system may work in the military, where training a soldier to be instantly and unquestioningly obedient to orders is an important part of success, but your users are (probably) not soldiers, and you've no need to demonstrate that you can limit their permissions just because you can.
All that will be accomplished by creating artificial and unnecessary limitations will be a sense of resentment, a lack of serious effort in adhering to those policies that you really do require for maintaining security, a disinterest in performing in the spirit of those policies when situations are discovered that the policies do not cover, and subsequent work to undermine the security measures you have in place.
Although it's a rare trait in administrators, we'd like you to consider treating your users as though they deserve the trust and responsibility they've been granted by being given accounts. Too many administrators give out user accounts and then immediately act as though the users are betraying a trust when they make use of the abilities they've been given. If you truly want to prevent an action, it absolutely must be clear to the users, and it is best if more than a policy rule prevents it.
Actions such as running Crack on a password file, however, are rather equivocal as far as the user's behavior is concerned . Perhaps the user is actually trying to steal your system passwords, or perhaps is curious how quickly Crack runs on your system compared to the machine at home. Users occasionally do things that a cracker would do, simply out of idle curiosity . This does not make them crackers, and does not make them any less trustworthy than they were when you granted them the account.
If you observe a user doing something that is questionable, do your best to determine why they're doing it. Examine whether they still appear to be deserving of the same trust they were when you granted their accounts, and if they are, and their explanations are innocent, then it's probably in your best interest to believe them. All the good hackers of the world got there by experimentation and investigation of the way the system works. The oddball user that you tolerate in his experimentation might not turn out to be the next Wietse Venema (ftp://ftp.porcupine.org/pub/security/index.html), but on the other hand, he might. If you shepherd his curiosity to more useful subjects, and don't crucify him over transgressions that are actually only conceptual violations, you're likely to have a much more positive result. At the worst, he'll probably eschew most further experimentation because he won't anticipate you are much more astute. At the best, however, you'll find that in deference to your consideration in not tossing their butts out on the street, these individuals will take it upon themselves to be helpful above and beyond the call, and will function as some of your best security warning devices for your system. At the very least, he'll probably avoid using your internal corporate politics and the brain damage in the design of your security systems as topics in the security book he writes ten years later.