Feature Requests for 1.5 (or whatever)

Ken Raeburn raeburn at MIT.EDU
Wed Feb 23 14:16:58 EST 2005

On Feb 23, 2005, at 11:45, Henry B. Hotz wrote:

> 1a) Provide a way to import Kerberos databases from non-MIT sources.
> 1b)  Provide a way to import specific Kerberos principals/keys from 
> non-MIT sources.

Would be nice to have, yes....

> 2)  Provide a better credentials cache storage mechanism, more like 
> The /tmp files are nicely cross-platform, but they make kind of an 
> obvious target, and they stay around if you take the disk out of the 
> machine.  Also having different scoping rules for AFS tokens and 
> Kerberos tickets seems an invitation for security problems.

Putting /tmp in a memory file system should deal (somewhat) with the 
issue of taking the disk out of the machine.  (Making it encrypted when 
swapping out of main memory would help even more.)  If /tmp can't be a 
memory file system, then perhaps a small file system mounted someplace 
else, into which we put the credentials caches and other such data.  
Quotas or per-user/session memory file systems could address the 
obvious denial-of-service attacks between users.

Problem is, all of this is dependent on the local machine's 
configuration and OS, causing hassles for the sysadmin if they want 
their machines set up differently, and portability hassles for us if 
some OS doesn't always have some capability of this sort built in.

Now, if we want to talk about, say, a config file option indicating a 
way to construct the default ccache name for the login program (or PAM 
module we don't control, or SSH code we don't control, etc) possibly 
using environment variables or uids or whatever, that's doable, and 
it's a building block that a sysadmin could perhaps use to build a 
setup like I described above.

The AFS PAG is *much* more OS dependent, and I think it's safe to say 
that we're not going to get into writing kernel modules any time soon.  
If a facility becomes available on an OS (and I've heard rumor that 
something probably will be coming for Linux), perhaps we can use it, 
but if it's not already there, we're not going to be inventing it.

> I like the chroot-like properties of the AFS PAG.  You can get into a 
> new context, but you can't get out.  It's hard(er) for someone to 
> break into a context.  Two separate logins to the same machine stay 
> separate.

Let's see... ptrace, ~/.cshrc, ~/bin, I can come up with several ways 
for one login/PAG to use credentials associated with another login/PAG 
under the same uid.

And I don't know about AFS specifically, but Kerberos would need to be 
able to read back all of the stored data, so such cross-session 
intrusions could include stealing the credentials and using the copies 
even after the user has destroyed the originals.


More information about the krbdev mailing list