True Distributed Security

The new HCOOP infrastructure implements true distributed security, unlike systems such as NFS/NIS and NTLM, which do not.

Understanding True Distributed Security

In order to understand the reasoning behind this, you first need to project yourself into the future where HCOOP has grown to the point where it has several machines like mire (that is, user-login machines) and a small number of security-critical machines like deleuze (KDC, passwords, AFS service).

With a system that does not implement distributed security (like NIS/NFS), the entire network implicitly trusts local root on every machine on the network. This means that with a system like NIS/NFS, if a rougue user somehow managed to compromise "local root" on any on e of the mire machines, that user would instantly have full access to every account (including admin accounts) on every machine throughout all of HCOOP. This is not a wise approach to security.

By contrast, Kerberos (and by virtue of using it, AFS) implement true distributed security. Deleuze does not trust mire any more than it trusts your laptop on your desk at home. As we add more user servers, they too will be untrusted. Because deleuze only runs the minimal set of security-critical services, this makes HCOOP very robust. Hopefully in the future we will be moving even more services off of deleuze, until it does nothing but Kerberos and AFS (but we'll need more hardware before this is practical).

The Price of Security

However, not trusting mire comes at a price. Your files live on deleuze (in AFS), but you're logged in to mire. How does deleuze know that you should be trusted to access your own files? It can't just say "oh, I trust whatever mire says, so if mire says it's AdamC (one of the root admins), I'll let him access anything." That would be incredibly poor security.

Instead, when you log in to mire via ssh, you type your password, which mire then uses to prove your identity to deleuze. Deleuze issues "Kerberos Tickets" and "AFS Tokens" (which are basically the same thing; don't worry about the difference right now) that you can then use to prove your identity.

Limited Ticket Lifetimes and Renewal Limits

These tickets and tokens have a limited lifetime -- currently on HCOOP they expire after 24 hours. This is important: if these tickets and tokens did not have expiration dates, they would be basically equivalent to your password. Anybody who stole these "immortal tickets" (say, by hacking one of the mires) could pretend to be you, forever, and you would be none the wiser. This would be just as bad as keeping your password sitting on the disk on mire.

There is a consequence to these limited lifetimes: once your tickets+tokens expire, you can no longer access AFS. This means that you must log out and log back in every 24 hours in order to continue accessing your home directory. However, if you're quite determined, there's also a way to renew your tickets without a password (see "man kinit" and look for "renewing tickets"). You can do this for up to seven days -- after seven days your renewals will be refused and you must obtain a fresh ticket.

No SSH Public Key Authentication

There is also another consequence to the tickets+tokens strategy: you must type your password when logging in so that mire can get tickets and tokens for you. SSH public key authentication will not work. However, you can obtain tickets and tokens on your personal computer (ie the machine you're sitting in front of), and use those tickets to log in to mire without using a password. See "man ssh" for the "-K" option or "man ssh_config" and search for "GSSAPI" (which one you use depends on what kind of ssh client you have).

In theory, it would be possible for deleuze to accept proof that you hold your ssh private key as proof of your identity by proxy via the ssh-agent, and issue tickets+tokens based on this. Currently nobody has written a Kerberos Domain Controller that knows how to do this, but we're pretty close to being able to (see this [http://thread.gmane.org/gmane.comp.encryption.kerberos.general/10549/focus=10578 post] and read the rest of the thread). AdamM is thinking about the scheme mentioned in the post, but doesn't currently know when he'll have time to write the required code.