Re: Kerberos on diskless clients
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?
Reply to: