Re: Kerberos on diskless clients

[Jonas Smedegaard <jonas@jones.dk>]

On Tue, Jun 15, 2010 at 12:02:57PM +0200, John S. Skogtvedt wrote:
> Den 15. juni 2010 11:01, skrev Jonas Smedegaard:
> > On Tue, Jun 15, 2010 at 09:07:35AM +0200, John S. Skogtvedt wrote:
> > > sorry for my late entry to the discussion on kerberos. It's really 
> > > good that you're working on it.
> > >
> > > I wonder, has anybody thought about how to implement Kerberos+NFSv4 
> > > on diskless clients?
> > > My understanding is that every workstation needs to have a 
> > > "$hostname/nfs" principal in Kerberos, with a secret key. Every 
> > > machine which presents a correct principal and key can read the 
> > > exported filesystem, but to write to it you need to authenticate to 
> > > kerberos (with a user principal). If any of this is incorrect, 
> > > please correct me.
> > >
> > > As the diskless filesystem is (by necessity) available to anyone, 
> > > putting Kerberos keys for all clients there would be no more secure 
> > > than NFSv3. One idea is to put the key on a HD or CF card, another 
> > > is to put the encrypted keys in the chroot and prompt the admin for 
> > > the password at boot. Of course, both of these suffer from the 
> > > problem that the server can't be trusted (e.g. a second server on 
> > > the network serving a filesystem which gathers keys and passwords).
> >
> > How about this:
> >
> >  1) Serve (like now?) root filesystem read-only using unencrypted nfs
> >  2) Add (like now?) local ram-based overlays to writable parts like 
> >     /var
> >  3) Authenticate using Kerberos at login time
> >  4) Mount /home using nfs v4
> >
> >
> >  - Jonas
>
> Sorry, my email was unclear: I was talking about the /skole/tjener/home0
> filesystem. The / filesystem can stay on NFSv3 and needs to be readable
> to (nearly) all, writing to it is today handled by using ramdisks (using
> aufs would be better, but that's off topic).

Thanks for rephrasing: Yes, this is exactly what I meant.


> With /skole/tjener/home0, the problem is that the machine itself needs a
> "$hostname/nfs" principal with corresponding secret key. It's not enough
> that the user can authenticate to Kerberos.

Oh. I was unaware that the machine needed a separate key for NFS.  
Problem, yes!

What exactly do a $host/nfs key grant access to? The whole partition, 
encrypted by user keys, or the whole partition, unencrypted?

Would AFS perhaps provide a key structure better suited for this?  My 
question here is _only_ about the key structure - AFS might have other 
limitations making it unsuitable, but the act of comparing key handling 
might help understand possible/sane approaches.

Ideally we would use a filesystem requiring only user key to 
authenticate.  Hmm - would it perhaps be possible (while still secure) 
to create and permiy a $user/nfs keypair acting as host key for 
.../home* mount points?


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature