'cc the kerne list -->Andy On Fri, Dec 2, 2016 at 8:46 AM, Lukas Hejtmanek <xhejtman@xxxxxxxxx> wrote: > On Fri, Dec 02, 2016 at 08:26:33AM -0500, Andy Adamson wrote: >> 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! > > no, it is not, that is misunderstanding. kinit does not store anything in > $HOME. Tickets are in /tmp (or maybe in $TMPDIR). However, knit searches for > ~/.krb5/config at start and ~ is Kerberzied. Maybe silly design, but not mine > but kerberos guys (MIT ones). So, how does sshd allow the user to kinit on login? 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? > >> >> >> 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, Maybe the NFS client machine key maps to nobody/nogroup in your environment, but it does not in others. Other environments can (and do) map the machine cred to any UID they want - including root. user ssh's into the NFS client machine. >> 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!! > > again, huge misunderstanding. The thing I want is that user without his/her > ticket is mapped to nobody/nogroup identity. In your environment, UID 0 on the client machine (the machine credential in the host keytab) is mapped to nobody/nobody when accessing the NFS server. > I do not want any shortcut to > fake user ticket or something. I just want the user without ticket to be > allowed access kerberized home with nfs/$HOSTNAME identity, i.e., the same > identity as root user uses. So potential attacker gets nothing more than > already has if he escalates root access. And yes, the attacker has limited > access to kerberized share if only user account is compromised. But this is > the decision of NFS client machine administrator. If root access is > compromised (still, it is gssd specific and nothing prevents the attacker to > build such patch on his own), there is nothing that attackers get. > > -- > 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
