Yes, we should allow for the possibility of GSS mechanisms other than krb5. Matt On Mon, Nov 27, 2017 at 12:34 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 2017-11-27 at 11:46 -0500, Bruce Fields wrote: >> On Sun, Nov 26, 2017 at 10:53:45AM -0500, Chuck Lever wrote: >> > >> > > On Nov 26, 2017, at 6:58 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> > > >> > > On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: >> > > > > On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: >> > > > > >> > > > > On Tue, Nov 07, 2017 at 09:01:26AM -0500, Jeff Layton wrote: >> > > > > > On Tue, 2017-11-07 at 13:31 +0000, Stefan Hajnoczi wrote: >> > > > > > > On Tue, Oct 31, 2017 at 10:10:38AM -0400, Jeff Layton wrote: >> > > > > > > > On Fri, 2017-06-30 at 14:23 +0100, Stefan Hajnoczi wrote: >> > > > > > > > > @@ -595,6 +609,10 @@ int svc_port_is_privileged(struct sockaddr *sin) >> > > > > > > > > case AF_INET6: >> > > > > > > > > return ntohs(((struct sockaddr_in6 *)sin)->sin6_port) >> > > > > > > > > < PROT_SOCK; >> > > > > > > > > + case AF_VSOCK: >> > > > > > > > > + return ((struct sockaddr_vm *)sin)->svm_port <= >> > > > > > > > > + LAST_RESERVED_PORT; >> > > > > > > > > + >> > > > > > > > > default: >> > > > > > > > > return 0; >> > > > > > > > > } >> > > > > > > > >> > > > > > > > Does vsock even have the concept of a privileged port? I would imagine >> > > > > > > > that root in a guest VM would carry no particular significance from an >> > > > > > > > export security standpoint >> > > > > > > > >> > > > > > > > Since you're defining a new transport here, it might be nice write the >> > > > > > > > RFCs to avoid that distinction, if possible. >> > > > > > > > >> > > > > > > > Note that RDMA just has svc_port_is_privileged always return 1. >> > > > > > > >> > > > > > > AF_VSOCK has the same 0-1023 privileged port range as TCP. >> > > > > > > >> > > > > > >> > > > > > But why? And, given that you have 32-bits for a port with AF_VSOCK vs >> > > > > > the 16 bits on an AF_INET/AF_INET6, why is the range so pitifully small? >> > > > > > >> > > > > > Reserved ports are a bit of a dinosaur holdover from when being root on >> > > > > > a machine on the Internet meant something. With v4.1 it's much less of >> > > > > > an issue, but in the "olden days", reserved port exhaustion could be a >> > > > > > real problem. >> > > > > > >> > > > > > Mandating low ports can also be a problem in other way. Some well known >> > > > > > services use ports in the ephemeral range, and if your service starts >> > > > > > late and someone else has taken the port for an ephemeral one, you're >> > > > > > out of luck. >> > > > > > >> > > > > > I think we have to ask ourselves: >> > > > > > >> > > > > > Should the ability to open a low port inside of a VM carry any >> > > > > > significance at all to an RPC server? I'd suggest not, and I think it'd >> > > > > > be good to word the RFC to make that explicitly clear. >> > > > > >> > > > > AF_VSOCK has had the reserved port range since it was first merged in >> > > > > 2013. That's before my time but I do see some use for identifying >> > > > > connections coming from privileged processes. >> > > > > >> > > > > Given that TCP has the same privileged port range, is there any reason >> > > > > why AF_VSOCK would be any worse off than TCP for having it? >> > > > >> > > > I agree with Jeff that we need to think carefully about this. >> > > > >> > > > I don't especially care for the privileged port check, but: >> > > > >> > > > In this case, you are inventing an RPC transport that makes >> > > > it impossible to use strong security (ie, RPCSEC_GSS). We >> > > > should be careful about removing the check because only >> > > > AUTH_NULL and AUTH_UNIX security can be used in this kind >> > > > of deployment. >> > > > >> > > >> > > I know we've discussed this a bit, but does this transport _really_ >> > > preclude us from using RPCSEC_GSS? I know we don't have IP addresses >> > > here, but hosts on either end of a vsocket will have hostnames. >> > >> > Yes, even for AUTH_UNIX, something has to go in the "hostname" >> > field in the credential. Let's say the guest's uname. >> > >> > >> > > WRT kerberos, I don't see a reason why both hosts couldn't communicate >> > > with a KDC via other means, get tickets and then use those for >> > > authenticating over their vsock connection. vsock might make it harder >> > > to determine what SPN to use, but we could potentially work around that >> > > in other ways. >> > >> > "No network configuration" implies to me that the KDC (or >> > a proxy for it) would have to reside on the host. > > A proxy would be fine. The whole point of krb5 is that you can't rely on > the network anyway... > >> >> Their requirement is that network configuration not be mandatory, not >> that it always be absent. >> >> Then again maybe rpcsec_gss/vsock loses any advantage over >> rpcsec_gss/tcp if the former always requires a network anyway. >> >> > > > Note also that the NFSv4 standards require that implementations >> > > > can support RPCSEC_GSS. NFSv4 on VSOCK cannot. Something will >> > > > have to be done about that. >> >> Which might be: "Make an argument for why that requirement produces no >> useful result in this case". ? > > > I guess it just seems like we can allow RPCSEC_GSS over this channel, > even if it's not terribly useful today. I don't think we ought to word > in a way that specifically forbids it, unless it really does fall short > of some key requirement. > > GSSAPI is more than just krb5 too...maybe LIPKEY will make a comeback > someday? :) > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > -- > 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 -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 -- 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
