Unix Password and Authority Management

January 31st, 2011

One of the things that everyone seems to do different is managing passwords. We haven’t looked at that in quite some time, despite growth both of the company and the IT department.

As I look to us moving some things to the cloud, and shifting offsite backups from carrying tapes to a bank to backups via the Internet, I’m aware that the potential for mischief — whether intentional or not — is magnified. With cloud hosting, a person could, with the press of a button, wipe out the equivalent of racks of machines in a few seconds. With disk-based local and Internet-based offsite backups, the potential for malicious behavior may be magnified; someone could pretty quickly wipe out local and remote backups.

Add to that the mysterious fact that many enterprise-targeted services allow only a single username/password for an account, and make no provision for ACLs to delegate permissions to others. Even Rackspace Cloud has this problem, as do their JungleDisk backup product, and many, many other offsite backup products. Amazon AWS seems to be the only real exception to this rule, and their ACL support is more than a little complicated.

So one of the questions we will have to address is the balance of who has these passwords. Too many people and the probability of trouble, intentional or not, rises. Too few and productivity is harmed, and potentially also the ability to restore. (If only one person has the password, and that person is unavailable, company data may be as well.) The company does have some storage locations, including locked vaults and safe deposit boxes, that no IT people have access to. I am thinking that putting a record of passwords in those locations may be a good first step, as putting the passwords in the control of those that can’t use them seems a reasonable step.

But we’ve been thinking of this as it pertains to our local systems as well. We have, for a number of years now, assigned a unique root password to every server. These passwords are then stored in a password-management tool, encrypted with a master password, and stored on a shared filesystem. Everyone in the department therefore can access every password.

Many places where I worked used this scheme, or some variant of it. The general idea was that if root on one machine was compromised and the attacker got root’s password, it would prevent the person from being able to just try that password on the other servers on the network and achieve a greater level of intrusion.

However, the drawback is that we now have more servers than anyone can really remember the passwords for. So many people are just leaving the password tool running. Moreover, while the attack described above is still possible, these days I worry more about automated intrusion attempts that most likely won’t try that attack vector.

A couple of ways we could go may include using a single root password everywhere, or a small set of root passwords. Another option may be to not log in to root accounts at all — possibly even disabling their password — and requiring the use of user accounts plus sudo. This hasn’t been practical to date. We don’t want to make a dependency on LDAP from a bunch of machines just to be able to use root, and we haven’t been using a tool such as puppet or cfengine to manage this stuff. Using such a tool is on our roadmap and could let us manage that approach more easily. But this approach has risks too. One is that if user accounts can get to root on many machines, then we’re not really more secure than a standard root password. Second is that it makes it more difficult to detect and enforce password expiration and systematic password changes.

I’m curious what approaches other people are taking on this.

Categories: Linux

Leave a comment

Comments Feed6 Comments

  1. neutrinus

    think about creating uid=0 accounts for every admin (ex: neutrinusroot, thomasroot). Admins should have different passwords on servers… Then move to ssh keys :)
    Result: admin will have one password his key, ssh-agent will do the rest.

    Reply

    John Goerzen Reply:

    True, but then if an admin workstation (or, perhaps, laptop?) is compromised, then the same problem exists. Though this could indeed simplify the management, it is also impossible to police that people are using passworded keys.

    Reply

  2. natxo

    ldap + kerberos (soon moving homegrown setup to freeipa – freeipa.org)

    Reply

  3. Anonymous

    While you can’t enforce that people use passphrases on their SSH keys, if you show people how to set up libpam-ssh or libpam-gnome-keyring then they have no reason to use a passphraseless key. I always set up systems with passwords and remote root access disabled, sudo, and users with ssh keys only. When users don’t have passwords, you don’t have to worry about password policies. :)

    Reply

  4. Iñigo

    The main advantage of sudo is that you do _not_ need to give root.

    We use intensively /etc/sudoers to separate monitoring, backup, admin, developer, user, etc \roles\…

    This folks are doing some recommendations about the topic since years ago, in the man page, linked from the root welcome email message:

    http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot

    Reply

  5. Michael Goetze

    I think if the people who have root access to your systems can’t be trusted to run an SSH agent with expiry times and have passphrases on all their keys… then you should possibly rethink who has root access to your systems.

    Reply

Leave a comment

 

Feed

http://changelog.complete.org / Unix Password and Authority Management