> -----Original Message----- > From: Myklebust, Trond > Sent: Tuesday, September 20, 2011 7:39 PM > To: 'paul.szabo@xxxxxxxxxxxxx' > Cc: linux-nfs@xxxxxxxxxxxxxxx > Subject: RE: Please support NSF squashing multiple groups > > > -----Original Message----- > > From: paul.szabo@xxxxxxxxxxxxx [mailto:paul.szabo@xxxxxxxxxxxxx] > > Sent: Tuesday, September 20, 2011 7:29 PM > > To: Myklebust, Trond > > Cc: linux-nfs@xxxxxxxxxxxxxxx > > Subject: Re: Please support NSF squashing multiple groups > > > > Dear Trond, > > > > > ... what you are proposing is a potential security problem. > > > > Yes, definitely: if ever such options were implemented, then potential > > users should evaluate whether using them (or not using them) > > introduced a security vulnerability. That said... > > > > NFS security traditionally depended on UIDs and GIDs being "in sync" > > between the server and the clients. My proposal simply would enforce > > all GIDs to be "in sync" with the UID, as per server view; most often > > that would be a no-op (except for accesses by setuid or setgid apps). > > > > Seems that kerberos has no concept of groups but only of "principals" > > which are somewhat like UIDs. My proposal would bring NFSv3 in line > > with the NFSv4+krb model of "only the UID matters". > > That's a model which is incompatible with the way many people use the > AUTH_SYS authentication model. > > NFSroot setups etc _rely_ on being able to setgid() at will. They may also > require the group hack in order to work in environments where some people > have > 32 groups. > > Basically, the point is this: AUTH_SYS is inherently for use only in trusted > environments. It is too easy to fake a uid or a gid when you use a protocol > that exposes them in clear on the network and without providing any form of > secure integrity checking. > > > Kerberos is able to go beyond that trusted model (although it too has > limitations - particularly w.r.t. working in an environment where the client or > the server may have been compromised). However Kerberos will currently > limit your ability to setgid. The next generation of RPCSEC_GSS is expected to > lift that particular limitation, and will allow us to bring kerberos in line with > AUTH_SYS (albeit with greater security) rather than the other way round. Basically, what I'm trying to say is that I don't at all understand your threat model. You appear to be worried about a threat where a user can somehow usurp gids but not uids on the client. Why is that particular case of interest? Cheers Trond -- 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
