mbox series

[bpf,0/4] Expose network namespace cookies to user space

Message ID 20210210120425.53438-1-lmb@cloudflare.com
Headers show
Series Expose network namespace cookies to user space | expand

Message

Lorenz Bauer Feb. 10, 2021, 12:04 p.m. UTC
We're working on a user space control plane for the BPF sk_lookup
hook [1]. The hook attaches to a network namespace and allows
control over which socket receives a new connection / packet.

Roughly, applications can give a socket to our user space component
to participate in custom bind semantics. This creates an edge case
where  an application can provide us with a socket that lives in
a different network namespace than our BPF sk_lookup program.
We'd like to return an error in this case.

Additionally, we have some user space state that is tied to the
network namespace. We currently use the inode of the nsfs entry
in a directory name, but this is suffers from inode reuse.

I'm proposing to fix both of these issues by adding a new
SO_NETNS_COOKIE socket option as well as a NS_GET_COOKIE ioctl.
Using these we get a stable, unique identifier for a network
namespace and check whether a socket belongs to the "correct"
namespace.

NS_GET_COOKIE could be renamed to NS_GET_NET_COOKIE. I kept the
name generic because it seems like other namespace types could
benefit from a cookie as well.

I'm trying to land this via the bpf tree since this is where the
netns cookie originated, please let me know if this isn't
appropriate.

1: https://www.kernel.org/doc/html/latest/bpf/prog_sk_lookup.html

Cc: bpf@vger.kernel.org
Cc: linux-alpha@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: sparclinux@vger.kernel.org

Lorenz Bauer (4):
  net: add SO_NETNS_COOKIE socket option
  nsfs: add an ioctl to discover the network namespace cookie
  tools/testing: add test for NS_GET_COOKIE
  tools/testing: add a selftest for SO_NETNS_COOKIE

 arch/alpha/include/uapi/asm/socket.h          |  2 +
 arch/mips/include/uapi/asm/socket.h           |  2 +
 arch/parisc/include/uapi/asm/socket.h         |  2 +
 arch/sparc/include/uapi/asm/socket.h          |  2 +
 fs/nsfs.c                                     |  9 +++
 include/linux/sock_diag.h                     | 20 ++++++
 include/net/net_namespace.h                   | 11 ++++
 include/uapi/asm-generic/socket.h             |  2 +
 include/uapi/linux/nsfs.h                     |  2 +
 net/core/filter.c                             |  9 ++-
 net/core/sock.c                               |  7 +++
 tools/testing/selftests/net/.gitignore        |  1 +
 tools/testing/selftests/net/Makefile          |  2 +-
 tools/testing/selftests/net/so_netns_cookie.c | 61 +++++++++++++++++++
 tools/testing/selftests/nsfs/.gitignore       |  1 +
 tools/testing/selftests/nsfs/Makefile         |  2 +-
 tools/testing/selftests/nsfs/netns.c          | 57 +++++++++++++++++
 17 files changed, 185 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/net/so_netns_cookie.c
 create mode 100644 tools/testing/selftests/nsfs/netns.c

Comments

Christian Brauner March 1, 2021, 10:04 a.m. UTC | #1
On Wed, Feb 10, 2021 at 12:04:23PM +0000, Lorenz Bauer wrote:
> Network namespaces have a globally unique non-zero identifier aka a

> cookie, in line with socket cookies. Add an ioctl to retrieve the

> cookie from user space without going via BPF.

> 

> Cc: linux-api@vger.kernel.org

> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>

> ---

>  fs/nsfs.c                   |  9 +++++++++

>  include/net/net_namespace.h | 11 +++++++++++

>  include/uapi/linux/nsfs.h   |  2 ++

>  3 files changed, 22 insertions(+)

> 

> diff --git a/fs/nsfs.c b/fs/nsfs.c

> index 800c1d0eb0d0..d7865e39c049 100644

> --- a/fs/nsfs.c

> +++ b/fs/nsfs.c

> @@ -11,6 +11,7 @@

>  #include <linux/user_namespace.h>

>  #include <linux/nsfs.h>

>  #include <linux/uaccess.h>

> +#include <net/net_namespace.h>

>  

>  #include "internal.h"

>  

> @@ -191,6 +192,8 @@ static long ns_ioctl(struct file *filp, unsigned int ioctl,

>  	struct user_namespace *user_ns;

>  	struct ns_common *ns = get_proc_ns(file_inode(filp));

>  	uid_t __user *argp;

> +	struct net *net_ns;

> +	u64 cookie;

>  	uid_t uid;

>  

>  	switch (ioctl) {

> @@ -209,6 +212,12 @@ static long ns_ioctl(struct file *filp, unsigned int ioctl,

>  		argp = (uid_t __user *) arg;

>  		uid = from_kuid_munged(current_user_ns(), user_ns->owner);

>  		return put_user(uid, argp);

> +	case NS_GET_COOKIE:

> +		if (ns->ops->type != CLONE_NEWNET)

> +			return -EINVAL;

> +		net_ns = container_of(ns, struct net, ns);

> +		cookie = net_gen_cookie(net_ns);

> +		return put_user(cookie, (u64 __user *)arg);


Hey Lorenz,

Just to make sure: is it intentional that any user can retrieve the
cookie associated with any network namespace, i.e. you don't require any
form of permission checking in the owning user namespace of the network
namespace?

Christian
Lorenz Bauer March 2, 2021, 9:47 a.m. UTC | #2
On Mon, 1 Mar 2021 at 10:04, Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>

> Hey Lorenz,

>

> Just to make sure: is it intentional that any user can retrieve the

> cookie associated with any network namespace, i.e. you don't require any

> form of permission checking in the owning user namespace of the network

> namespace?

>

> Christian


Hi Christian,

I've decided to drop the patch set for now, but that was my intention, yes. Is
there a downside I'm not aware of?

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com
Christian Brauner March 2, 2021, 10:14 a.m. UTC | #3
On Tue, Mar 02, 2021 at 09:47:10AM +0000, Lorenz Bauer wrote:
> On Mon, 1 Mar 2021 at 10:04, Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> > Hey Lorenz,
> >
> > Just to make sure: is it intentional that any user can retrieve the
> > cookie associated with any network namespace, i.e. you don't require any
> > form of permission checking in the owning user namespace of the network
> > namespace?
> >
> > Christian
> 
> Hi Christian,
> 
> I've decided to drop the patch set for now, but that was my intention, yes. Is
> there a downside I'm not aware of?

It depends on whether this cookie is in any way security or at least
information sensitive. For example, would leaking it between
unprivileged containers with different user+network namespace pairs
allow one container to gain access to information about the other
container that it shouldn't.

Christian