welcome: please sign in

Diff for "MemberManual/DistributedSecurity"

Differences between revisions 12 and 17 (spanning 5 versions)
Revision 12 as of 2007-10-25 04:12:53
Size: 3904
Editor: MichaelOlson
Comment: take headings down a level
Revision 17 as of 2008-08-27 22:44:38
Size: 4276
Editor: netblock-68-183-203-20
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from RealSecurity
Line 6: Line 5:
[[TableOfContents]] <<TableOfContents>>
Line 17: Line 16:

=== This Actually Happened ===

In February of 2008 a linux kernel security hole was discovered. Within hours of the discovery being announced, [[https://lists.hcoop.net/pipermail/hcoop-announce/2008-February/000101.html|one of our own members used it to take control of mire]]. Had we not been using distributed security, that member would immediately have compromised 100% of all HCoop infrastructure.

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).

This Actually Happened

In February of 2008 a linux kernel security hole was discovered. Within hours of the discovery being announced, one of our own members used it to take control of mire. Had we not been using distributed security, that member would immediately have compromised 100% of all HCoop infrastructure.

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.

MemberManual/DistributedSecurity (last edited 2013-01-13 18:23:47 by ClintonEbadi)