| Message ID | 20170630132352.32133-9-stefanha@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 2017-06-30 at 14:23 +0100, Stefan Hajnoczi wrote: > Allow creation of AF_VSOCK service xprts. This is needed for the > "vsock-bc" backchannel. > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > --- > include/linux/sunrpc/svc_xprt.h | 12 ++++++++++++ > net/sunrpc/svc_xprt.c | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h > index ddb7f94..938f9ee 100644 > --- a/include/linux/sunrpc/svc_xprt.h > +++ b/include/linux/sunrpc/svc_xprt.h > @@ -8,6 +8,7 @@ > #define SUNRPC_SVC_XPRT_H > > #include <linux/sunrpc/svc.h> > +#include <linux/vm_sockets.h> > > struct module; > > @@ -156,12 +157,15 @@ static inline unsigned short svc_addr_port(const struct sockaddr *sa) > { > const struct sockaddr_in *sin = (const struct sockaddr_in *)sa; > const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)sa; > + const struct sockaddr_vm *svm = (const struct sockaddr_vm *)sa; > > switch (sa->sa_family) { > case AF_INET: > return ntohs(sin->sin_port); > case AF_INET6: > return ntohs(sin6->sin6_port); > + case AF_VSOCK: > + return svm->svm_port; > } > > return 0; > @@ -174,6 +178,8 @@ static inline size_t svc_addr_len(const struct sockaddr *sa) > return sizeof(struct sockaddr_in); > case AF_INET6: > return sizeof(struct sockaddr_in6); > + case AF_VSOCK: > + return sizeof(struct sockaddr_vm); > } > BUG(); > } > @@ -193,6 +199,7 @@ static inline char *__svc_print_addr(const struct sockaddr *addr, > { > const struct sockaddr_in *sin = (const struct sockaddr_in *)addr; > const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)addr; > + const struct sockaddr_vm *svm = (const struct sockaddr_vm *)addr; > > switch (addr->sa_family) { > case AF_INET: > @@ -206,6 +213,11 @@ static inline char *__svc_print_addr(const struct sockaddr *addr, > ntohs(sin6->sin6_port)); > break; > > + case AF_VSOCK: > + snprintf(buf, len, "%u, port=%u", > + svm->svm_cid, svm->svm_port); > + break; > + > default: > snprintf(buf, len, "unknown address type: %d", addr->sa_family); > break; > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c > index 7bfe1fb..2a8ccc1 100644 > --- a/net/sunrpc/svc_xprt.c > +++ b/net/sunrpc/svc_xprt.c > @@ -10,6 +10,7 @@ > #include <linux/kthread.h> > #include <linux/slab.h> > #include <net/sock.h> > +#include <net/af_vsock.h> > #include <linux/sunrpc/addr.h> > #include <linux/sunrpc/stats.h> > #include <linux/sunrpc/svc_xprt.h> > @@ -195,6 +196,13 @@ static struct svc_xprt *__svc_xpo_create(struct svc_xprt_class *xcl, > .sin6_port = htons(port), > }; > #endif > +#ifdef CONFIG_SUNRPC_XPRT_VSOCK > + struct sockaddr_vm svm = { > + .svm_family = AF_VSOCK, > + .svm_cid = VMADDR_CID_ANY, > + .svm_port = port, > + }; > +#endif > struct sockaddr *sap; > size_t len; > > @@ -209,6 +217,12 @@ static struct svc_xprt *__svc_xpo_create(struct svc_xprt_class *xcl, > len = sizeof(sin6); > break; > #endif > +#ifdef CONFIG_SUNRPC_XPRT_VSOCK > + case AF_VSOCK: > + sap = (struct sockaddr *)&svm; > + len = sizeof(svm); > + break; > +#endif > default: > return ERR_PTR(-EAFNOSUPPORT); > } > @@ -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.
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. Stefan
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.
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? Stefan
> On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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. Privileged ports are easy to spoof if there is an opportunity for a MitM attack to alter the port number of RPCs in transit. With VSOCK there may be no such opportunity, thus privileged ports might provide an adequate level of security here. I make that claim with no deep experience of VSOCK environments. When writing the VSOCK-related RFCs, you will need to provide a very clear and concise rationale to the IESG for purposely not supporting the use of RPCSEC_GSS. It will start with "well, these RPCs do not flow on open networks and are thus not subject to MitM attacks"; then proceed to careful discussion of how the server will guard against rogue users on guests, and assumptions about the trust relationship between the guests and the host. You will have to make AUTH_UNIX into a defensible deployment choice, and port privilege might be a part of that. 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. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 16, 2017 at 03:53:04PM -0500, Chuck Lever wrote: > > > On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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. > > Privileged ports are easy to spoof if there is an opportunity > for a MitM attack to alter the port number of RPCs in transit. > With VSOCK there may be no such opportunity, thus privileged > ports might provide an adequate level of security here. I > make that claim with no deep experience of VSOCK environments. > > When writing the VSOCK-related RFCs, you will need to provide > a very clear and concise rationale to the IESG for purposely > not supporting the use of RPCSEC_GSS. It will start with "well, > these RPCs do not flow on open networks and are thus not > subject to MitM attacks"; then proceed to careful discussion of > how the server will guard against rogue users on guests, and > assumptions about the trust relationship between the guests > and the host. You will have to make AUTH_UNIX into a defensible > deployment choice, and port privilege might be a part of that. > > 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. Thanks! I will cover it in the draft RFC. Stefan
On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: > > On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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. 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. > Privileged ports are easy to spoof if there is an opportunity > for a MitM attack to alter the port number of RPCs in transit. > With VSOCK there may be no such opportunity, thus privileged > ports might provide an adequate level of security here. I > make that claim with no deep experience of VSOCK environments. > > When writing the VSOCK-related RFCs, you will need to provide > a very clear and concise rationale to the IESG for purposely > not supporting the use of RPCSEC_GSS. It will start with "well, > these RPCs do not flow on open networks and are thus not > subject to MitM attacks"; then proceed to careful discussion of > how the server will guard against rogue users on guests, and > assumptions about the trust relationship between the guests > and the host. You will have to make AUTH_UNIX into a defensible > deployment choice, and port privilege might be a part of that. > > 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. > Good point on the reserved port value for AUTH_UNIX. That may be reason enough to keep it in.
> On Nov 26, 2017, at 6:58 AM, Jeff Layton <jlayton@redhat.com> wrote: > > On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: >>> On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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. Indeed, there's no a priori way of determining the NFS server SPN, other than to tell the guest somehow via a manual administrative interface or we pick a well-known value for it and make it part of the RPC-over-VSOCK spec. >> Privileged ports are easy to spoof if there is an opportunity >> for a MitM attack to alter the port number of RPCs in transit. >> With VSOCK there may be no such opportunity, thus privileged >> ports might provide an adequate level of security here. I >> make that claim with no deep experience of VSOCK environments. >> >> When writing the VSOCK-related RFCs, you will need to provide >> a very clear and concise rationale to the IESG for purposely >> not supporting the use of RPCSEC_GSS. It will start with "well, >> these RPCs do not flow on open networks and are thus not >> subject to MitM attacks"; then proceed to careful discussion of >> how the server will guard against rogue users on guests, and >> assumptions about the trust relationship between the guests >> and the host. You will have to make AUTH_UNIX into a defensible >> deployment choice, and port privilege might be a part of that. >> >> 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. >> > > Good point on the reserved port value for AUTH_UNIX. That may be reason > enough to keep it in. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 26, 2017 at 10:53:45AM -0500, Chuck Lever wrote: > > > On Nov 26, 2017, at 6:58 AM, Jeff Layton <jlayton@redhat.com> wrote: > > > > On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: > >>> On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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. 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". ? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@redhat.com> wrote: > > > > > > On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: > > > > > On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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? :)
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@redhat.com> 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@redhat.com> wrote: >> > > >> > > On Thu, 2017-11-16 at 15:53 -0500, Chuck Lever wrote: >> > > > > On Nov 16, 2017, at 10:25 AM, Stefan Hajnoczi <stefanha@redhat.com> 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@redhat.com> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h index ddb7f94..938f9ee 100644 --- a/include/linux/sunrpc/svc_xprt.h +++ b/include/linux/sunrpc/svc_xprt.h @@ -8,6 +8,7 @@ #define SUNRPC_SVC_XPRT_H #include <linux/sunrpc/svc.h> +#include <linux/vm_sockets.h> struct module; @@ -156,12 +157,15 @@ static inline unsigned short svc_addr_port(const struct sockaddr *sa) { const struct sockaddr_in *sin = (const struct sockaddr_in *)sa; const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)sa; + const struct sockaddr_vm *svm = (const struct sockaddr_vm *)sa; switch (sa->sa_family) { case AF_INET: return ntohs(sin->sin_port); case AF_INET6: return ntohs(sin6->sin6_port); + case AF_VSOCK: + return svm->svm_port; } return 0; @@ -174,6 +178,8 @@ static inline size_t svc_addr_len(const struct sockaddr *sa) return sizeof(struct sockaddr_in); case AF_INET6: return sizeof(struct sockaddr_in6); + case AF_VSOCK: + return sizeof(struct sockaddr_vm); } BUG(); } @@ -193,6 +199,7 @@ static inline char *__svc_print_addr(const struct sockaddr *addr, { const struct sockaddr_in *sin = (const struct sockaddr_in *)addr; const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)addr; + const struct sockaddr_vm *svm = (const struct sockaddr_vm *)addr; switch (addr->sa_family) { case AF_INET: @@ -206,6 +213,11 @@ static inline char *__svc_print_addr(const struct sockaddr *addr, ntohs(sin6->sin6_port)); break; + case AF_VSOCK: + snprintf(buf, len, "%u, port=%u", + svm->svm_cid, svm->svm_port); + break; + default: snprintf(buf, len, "unknown address type: %d", addr->sa_family); break; diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c index 7bfe1fb..2a8ccc1 100644 --- a/net/sunrpc/svc_xprt.c +++ b/net/sunrpc/svc_xprt.c @@ -10,6 +10,7 @@ #include <linux/kthread.h> #include <linux/slab.h> #include <net/sock.h> +#include <net/af_vsock.h> #include <linux/sunrpc/addr.h> #include <linux/sunrpc/stats.h> #include <linux/sunrpc/svc_xprt.h> @@ -195,6 +196,13 @@ static struct svc_xprt *__svc_xpo_create(struct svc_xprt_class *xcl, .sin6_port = htons(port), }; #endif +#ifdef CONFIG_SUNRPC_XPRT_VSOCK + struct sockaddr_vm svm = { + .svm_family = AF_VSOCK, + .svm_cid = VMADDR_CID_ANY, + .svm_port = port, + }; +#endif struct sockaddr *sap; size_t len; @@ -209,6 +217,12 @@ static struct svc_xprt *__svc_xpo_create(struct svc_xprt_class *xcl, len = sizeof(sin6); break; #endif +#ifdef CONFIG_SUNRPC_XPRT_VSOCK + case AF_VSOCK: + sap = (struct sockaddr *)&svm; + len = sizeof(svm); + break; +#endif default: return ERR_PTR(-EAFNOSUPPORT); } @@ -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; }
Allow creation of AF_VSOCK service xprts. This is needed for the "vsock-bc" backchannel. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> --- include/linux/sunrpc/svc_xprt.h | 12 ++++++++++++ net/sunrpc/svc_xprt.c | 18 ++++++++++++++++++ 2 files changed, 30 insertions(+)