Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access

> On Apr 14, 2024, at 15:30, Rick Macklem <rick.macklem@gmail.com> wrote:
> 
> On Sun, Apr 14, 2024 at 8:26 AM Andreas Kempe <kempe@lysator.liu.se> wrote:
>> 
>> On Sat, Mar 30, 2024 at 04:01:50PM -0700, Rick Macklem wrote:
>>> On Sat, Mar 30, 2024 at 2:45 PM Andreas Kempe <kempe@lysator.liu.se> wrote:
>>>> Did you have a look at the owner field in the open reqest that created
>>>> the file? To me, it looks very strange. Could it be that the client
>>>> isn't sending a correct owner in the creation request, causing the
>>>> server to map it to nobody?
>>> The only setable attribute specified by the Open request is "mode".
>>> That just means that the server is expected to create the file with
>>> an ownership of the Kerberos principal used in the RPC credentials.
>>> 
>>> Now, if you are doing the RPC as root, that will result in nobody (or
>>> a failure to create the file, depending upon directory permissions).
>>> There is no way to know what user principal is represented by the
>>> RPCSEC_GSS credentials, since they are a shorthand for the
>>> Kerberos credentials presented in a Null RPC that happens
>>> when there is no credential.
>>> 
>>> When creating a file, the user creating the file will need to have
>>> a valid TGT in the client's credential cache.
>>> 
>>> And the user principal name (without @REALM) must be a name
>>> in the passwd database.
>>> 
>> 
>> After having let this brew in the back of my mind for a while, I
>> realised what the issue was thanks to you explaining the use of the
>> principal to figure out the user.
>> 
>> For our usecase, I wanted to only authenticate the machine because
>> users have cronjobs running in their home directories, users want to
>> access each other's files and log in using SSH keys. I was mounting
>> using
>> 
>>        -o nfsv4,sec=krb5p,allgssname,gssname=host
>> 
>> thinking that allgssname would allow users to use the machine's
>> principal and that ownership information would be sent along with the
>> requests. From what you wrote, Rick, I gather that this causes all
>> users to be mapped to nobody because the machine's principal is used.
> Yes. All gssname means that the "host" keytab entry is used for all RPCs.
> What that maps to is up to the NFS server, but "nobody" would be the
> typical case.
> 
>> 
>> Removing allgssname and doing a kinit has things working as expected
>> when I mount using
>> 
>>        -o nfsv4,sec=krb5p,gssname=host
>> 
>> and makes me own files I create.
>> 
>> Am I correct in thinking that Kerberos isn't really designed to be
>> used for only authenticating the machine? Users having to always have
>> their own valid Kerberos ticket doesn't really work for us.
> Yes. The "host" keytab credential is a "hack". Kerberos calls them
> service principals and they were not intended to authenticate a machine
> when Kerberos was designed.
> 
> If users are running cron jobs, then one way around the problem
> is to have the KDC issue renewable tickets and then run a daemon
> (can't remember the name, but it is easy to find and opensourced)
> that renews TGTs. (This only works up to the renew limit of the KDC
> config.)
> 
> NFS-over-TLS (called RPC-over-TLS by the Linux folk) does allow
> a client to provide a X.509 certificate during TLS handshake to
> identify the client machine and the TLS encrypts everything on
> the wire to avoid middleman attacks or snoopers.
> It does not identify users on the server, unless TLS identity
> squashing is used via the X.509 certificate to make all RPCs
> done by a user. (This has the advantage that it is not "nobody",
> but is only useful for things like laptops, that are only used by
> one user. It does have the advantage that there are no tickets
> to expire, although there is a, usually long, expiration on the X.509
> certificate.)
> 
> rick
> 

Back when Kerberos was designed kerberized NFS servers had a table mapping client address and userid to server userid.  The table was managed by a daemon to which users sent Kerberos tickets for the NFS service.  It might have been a hacked rpc.mountd.  Client NFS requests used AUTH_UNIX, userid and group list.   The userid was checked in the table instead of being blindly trusted.  As was typical back then, the wire connection was unencrypted.  I think active users on the same subnet were potentially vulnerable to impersonation.  (At MIT a subnet was approximately a small building or a few floors of a large one.)   The concept should work better over an encrypted connection.

John Carr