Den 15. juni 2010 12:51, skrev Jonas Smedegaard: > 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? >
I'm not a Kerberos/NFSv4 expert, but AFAIK it's a ticket-granting ticket (TGT) which firstly gives the machine read-only access to the entire exported filesystem, and secondly allows the machine to grant a RW ticket to the user. Kerberos is used to authenticate writes, and optionally for encryption as well. > 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 > Don't know about these. Anyone? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
