|
Size: 4398
Comment:
|
Size: 3865
Comment: renamed to address note
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == True Distributed Security == | #pragma section-numbers off |
| Line 3: | Line 3: |
| The new HCOOP infrastructure implements true distributed security, unlike systems such as NFS/NIS and NTLM, which do not. | This page describes the rationale for Kerberos and AFS being the way they are. It also explains some things that people would not expect if they have never used either AFS or Kerberos. |
| Line 5: | Line 5: |
| === Understanding True Distributed Security === | [[TableOfContents]] The new HCoop infrastructure implements true distributed security, unlike systems such as NFS/NIS and NTLM, which do not. == Understanding True Distributed Security == |
| Line 9: | Line 13: |
| 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. | 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 rogue user somehow managed to compromise "local root" on any one 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. |
| Line 11: | Line 15: |
| 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). | By contrast, Kerberos (and by virtue of using it, AFS) implements 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). |
| Line 13: | Line 17: |
| === The Price of Security === | == The Price of Security == |
| Line 15: | Line 19: |
| 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. | 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. |
| Line 19: | Line 23: |
| ==== Limited Ticket Lifetimes and Renewal Limits ==== | === Limited Ticket Lifetimes and Renewal Limits === |
| Line 21: | Line 25: |
| 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. | 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. |
| Line 23: | Line 27: |
| 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. | 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. You can also renew your tickets without a password by typing "`kinit -R;aklog`" ''before'' your tickets expire -- but this will only work for seven days; you can't renew tickets longer than that without getting fresh ones. |
| Line 25: | Line 29: |
| ==== No SSH Public Key Authentication ==== | === No SSH Public Key Authentication === |
| Line 27: | Line 31: |
| 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. |
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. For more information, see PasswordlessLogin. |
This page describes the rationale for Kerberos and AFS being the way they are. It also explains some things that people would not expect if they have never used either AFS or Kerberos.
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 rogue user somehow managed to compromise "local root" on any one 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) implements 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. You can also renew your tickets without a password by typing "kinit -R;aklog" before your tickets expire -- but this will only work for seven days; you can't renew tickets longer than that without getting fresh ones.
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. For more information, see PasswordlessLogin.