Oops - forgot to 'cc the kernel list. -->andy ---------- Forwarded message ---------- From: Andy Adamson <androsadamson@xxxxxxxxx> Date: Fri, Dec 2, 2016 at 8:26 AM Subject: Re: RFC rpc.gssd enhancement To: Lukas Hejtmanek <xhejtman@xxxxxxxxxxx> On Fri, Dec 2, 2016 at 6:41 AM, Lukas Hejtmanek <xhejtman@xxxxxxxxxxx> wrote: > On Tue, Nov 29, 2016 at 02:28:10PM -0500, Steve Dickson wrote: >> > maybe it is not considered secure, but it is still more secure to me than >> > using sec=sys. That is not saying much. AUTH_SYS is _completely_ insecure. RPCSEC_GSS with Kerberos is as secure as we get. Watering down Kerberos security is silly. AFAICS, the only reason kinit of the user to re-establish the Kerberos GSS context for NFS is the fact that the result of the kinit is stored in NFS under Kerberos. That is a silly design! >> True. > > So, I was asking, if I provide such patch, will it be accepted into mainline > nfs-utils? It shouldn't be. I strongly object. Just to be clear, here is what you are asking: >>So, I think in this case, I would like to see rpc.gssd uses host keytab while >>user's ticket is not available, which maps to nobody/nogroup, but kinit should succeed. If the above were implemented - an attacker that has rooted the NFS client machine, or got control of gssd in some way - which means the attacker has the NFS client machine key, can kinit as _any_ user at _any_ time and access _any_ users kerberos NFS share accessible from the client machine. That is a huge security hole and a very large security degradation!! In the current situation, rooting the NFS client machine only gives access (with a lot of hacking) to the non-expired in-kernel GSS contexts of active NFS users. Once the GSS context expires, the attacker has nothing. > >> > the problem is, that kerberized home is problem for .k5login file and also for >> > .ssh/authorized_keys. While the .k5login file is accessed with root context >> > (sshd), the authorized_keys is accessed with user context, so login via ssh >> > pubkey is not possible at all. That is no reason to degrade Kerberos security! I don't get this: Here are the steps to allow the user to access the NFS kerberized share: 1) machine has NFS mounted /home using kerberos authentication 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world readable to allow kerberized access, e.g., using kerberos ticket) Why does the user kinit (e.g. the user logs in) allow sshd to create the initial krb ticket in $HOME/<whatever> yet the user kinit to renew said krb ticket fail? That seems to be a silly design. >> What would the .k5login look like and what would the principal look like? >> My apologies but I'm not very familar with how sshd interacts with >> the .k5login. > > ok, I did more testing. It seems that kinit does not search ~/.k5login but > ~/.krb5/config. > > If NFS client gets permission denied, it is ok and kinit just creates a new > ticket. Huh? What kinit? The NFS client (using the machine key) uses a keytab which means no kinit is required. Using a keytab is one way to have renewable Kerberos credentials. The correct way to solve your problem is with renewable tickets. I suggest you read: https://web.mit.edu/kerberos/krb5-1.13/doc/user/tkt_mgmt.html which includes: "Renewable tickets can be used to obtain new session keys without the user entering their password again. A renewable ticket has two expiration times. The first is the time at which this particular ticket expires. The second is the latest possible expiration time for any ticket issued based on this renewable ticket." Or perhaps this from microsoft: https://social.technet.microsoft.com/Forums/windowsserver/en-US/e0c6a401-1609-47c9-8f1c-6437b98bef2a/how-does-kerberos-ticket-or-tgt-get-renewed-or-refreshed?forum=winserversecurity "When tickets are renewable, session keys are refreshed periodically without issuing a completely new ticket. If Kerberos policy permits renewable tickets, the KDC sets a RENEWABLE flag in every ticket it issues and sets two expiration times in the ticket. One expiration time limits the life of the current instance of the ticket; the second expiration time sets a limit on the cumulative lifetime of all instances of the ticket. The expiration time for the current instance of the ticket is held in the End Time field. As with non-renewable tickets, the value in the End Time field equals the value in the Start Time field plus the value of the maximum ticket life specified by Kerberos policy. A client holding a renewable ticket must send it—presenting a fresh authenticator as well—to the KDC for renewal before the end time is reached. When the KDC receives a ticket for renewal, it checks the value of a second expiration time held in the Renew Till field. This value is set when the ticket is first issued. It equals the value in the tickets Start Time field plus the value of the maximum cumulative ticket life specified by Kerberos policy. When the KDC renews the ticket, it checks to determine if the renew-till time has not yet arrived. If it has not, the KDC issues a new instance of the ticket with a later end time and a new session key. This means that administrators can set Kerberos policy so that tickets must be renewed at relatively short intervals—every day, for example. When tickets are renewed, a new session key is issued, minimizing the value of a compromised key. Administrators can also set cumulative ticket life for a relatively long period—one week or one month, for example. At the end of that time, the ticket expires and is no longer valid for renewal." There are many ways to set this up. https://linux.die.net/man/1/krenew As Steve Dickson mentioned, Red Hat SSSD does ticket renewal > > However, if user has ticket that expired, NFS client returns EKEYEXPIRED > instead of EPERM. That is because the key has expired!!! #define EKEYEXPIRED 127 /* Key has expired */ so EKEYEXPIRED is obviously the correct error! > In such a case, kinit/kdestoy does not deal with this errno > and returns: > kinit: krb5_init_context failed: 127 > or > kdestroy: krb5_init_context failed: 127 > > if you do rm /tmp/krb5cc_`id -u`_*, EKEYEXPIRED is changed to EPERM and > kinit/kdestroy works again. > > > Colleague of me says that EKEYEPIRED should not be returned by NFS client at > all, EPERM should be always returned and he sees this as a bug in kernel code. No! EKEYEXPIRED is used to signal the user that the only reason for the failure is that the user's credentials have expired, and that the user therefore needs to renew her credentials. EKEYEXPIRED is exactly the error to return. -->Andy > > -- > Lukáš Hejtmánek > -- > 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 -- 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
