Hi It is common in certain cases for a Linux workstation administrator to create a shared account with a corresponding .k5login file. Kerberos principal strings for users are added to the .k5login and the corresponding users can logon as the local shared account using their Kerberos credentials. Once logged on to the workstation, the user's local identity (local to the workstation) is the UID of the local shared account; however, when accessing kerberized resources external to the workstation (for example NFSv4 volumes), the user's identity is expected to be the individual user's kerberos identity. I am seeing the following serious security issue: If N users (user1@REALM , user2@REALM ...userN@REALM) (who are listed sharusr's .k5login) all logon to workstation1 as sharusr and are all running sessions simultaneously, then, the GSS Context / kerberos credentials stored in and used by the NFS-client kernel code when processing NFS requests on behalf of a user, will be correct for 1 user and incorrect for N-1 users. Each of the N-1 users will not be able to access NFS server resources that only they have been granted access to; but, they will be able to access all NFS resources that the 1 user has been granted access to. (even if their kerberos identity has not been granted access). Even after each of the N-1 users destroys their credentials they still retain access to all NFS resources that the 1 user has been granted access to. Access will not be denied until the 1 user also destroys his / her credentials. It is my understanding that the RPC GSS kernel module on an NFS client system, keeps a GSS security context (copy of a user's credentials) that it uses when it communicates with the NFS server on the user's behalf. I believe that the kernel security context relates back to the user mode process solely by UID number. Would adding session ID to the relation resolve the issue ? Each Session for each user would then have a unique tuple (UID,SessionID) that would map to the *correct* GSS Security context in the kernel. Thanks Andy Romero romero@xxxxxxxx NAS / SAN Administrator, Fermilab -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
