netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@fomichev.me>
To: Song Liu <songliubraving@fb.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, ast@kernel.org,
	daniel@iogearbox.net, kernel-team@fb.com
Subject: Re: [PATCH bpf-next 0/4] sys_bpf() access control via /dev/bpf
Date: Tue, 25 Jun 2019 13:51:55 -0700	[thread overview]
Message-ID: <20190625205155.GD10487@mini-arch> (raw)
In-Reply-To: <20190625182303.874270-1-songliubraving@fb.com>

On 06/25, Song Liu wrote:
> Currently, most access to sys_bpf() is limited to root. However, there are
> use cases that would benefit from non-privileged use of sys_bpf(), e.g.
> systemd.
> 
> This set introduces a new model to control the access to sys_bpf(). A
> special device, /dev/bpf, is introduced to manage access to sys_bpf().
> Users with access to open /dev/bpf will be able to access most of
> sys_bpf() features. The use can get access to sys_bpf() by opening /dev/bpf
> and use ioctl to get/put permission.
> 
> The permission to access sys_bpf() is marked by bit TASK_BPF_FLAG_PERMITTED
> in task_struct. During fork(), child will not inherit this bit.
2c: if we are going to have an fd, I'd vote for a proper fd based access
checks instead of a per-task flag, so we can do:
	ioctl(fd, BPF_MAP_CREATE, uattr, sizeof(uattr))

(and pass this fd around)

I do understand that it breaks current assumptions that libbpf has,
but maybe we can extend _xattr variants to accept optinal fd (and try
to fallback to sysctl if it's absent/not working)?

> libbpf APIs libbpf_[get|put]_bpf_permission() are added to help get and
> put the permission. bpftool is updated to use these APIs.
> 
> Song Liu (4):
>   bpf: unprivileged BPF access via /dev/bpf
>   bpf: sync tools/include/uapi/linux/bpf.h
>   libbpf: add libbpf_[get|put]_bpf_permission()
>   bpftool: use libbpf_[get|put]_bpf_permission()
> 
>  Documentation/ioctl/ioctl-number.txt |  1 +
>  include/linux/bpf.h                  | 12 +++++
>  include/linux/sched.h                |  8 ++++
>  include/uapi/linux/bpf.h             |  5 ++
>  kernel/bpf/arraymap.c                |  2 +-
>  kernel/bpf/cgroup.c                  |  2 +-
>  kernel/bpf/core.c                    |  4 +-
>  kernel/bpf/cpumap.c                  |  2 +-
>  kernel/bpf/devmap.c                  |  2 +-
>  kernel/bpf/hashtab.c                 |  4 +-
>  kernel/bpf/lpm_trie.c                |  2 +-
>  kernel/bpf/offload.c                 |  2 +-
>  kernel/bpf/queue_stack_maps.c        |  2 +-
>  kernel/bpf/reuseport_array.c         |  2 +-
>  kernel/bpf/stackmap.c                |  2 +-
>  kernel/bpf/syscall.c                 | 72 +++++++++++++++++++++-------
>  kernel/bpf/verifier.c                |  2 +-
>  kernel/bpf/xskmap.c                  |  2 +-
>  kernel/fork.c                        |  4 ++
>  net/core/filter.c                    |  6 +--
>  tools/bpf/bpftool/feature.c          |  2 +-
>  tools/bpf/bpftool/main.c             |  5 ++
>  tools/include/uapi/linux/bpf.h       |  5 ++
>  tools/lib/bpf/libbpf.c               | 54 +++++++++++++++++++++
>  tools/lib/bpf/libbpf.h               |  7 +++
>  tools/lib/bpf/libbpf.map             |  2 +
>  26 files changed, 178 insertions(+), 35 deletions(-)
> 
> --
> 2.17.1

  parent reply	other threads:[~2019-06-25 20:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 18:22 [PATCH bpf-next 0/4] sys_bpf() access control via /dev/bpf Song Liu
2019-06-25 18:23 ` [PATCH bpf-next 1/4] bpf: unprivileged BPF access " Song Liu
2019-06-26 13:32   ` Daniel Borkmann
2019-06-26 15:17     ` Song Liu
2019-06-27  0:08       ` Greg KH
2019-06-27  1:00         ` Song Liu
2019-06-27 16:37           ` Greg KH
2019-06-27 16:51             ` Song Liu
2019-06-27 17:00               ` Greg KH
2019-06-26 13:45   ` Lorenz Bauer
2019-06-26 15:19     ` Song Liu
2019-06-26 15:26       ` Lorenz Bauer
2019-06-26 16:10         ` Song Liu
2019-06-25 18:23 ` [PATCH bpf-next 2/4] bpf: sync tools/include/uapi/linux/bpf.h Song Liu
2019-06-25 18:23 ` [PATCH bpf-next 3/4] libbpf: add libbpf_[get|put]_bpf_permission() Song Liu
2019-06-25 18:23 ` [PATCH bpf-next 4/4] bpftool: use libbpf_[get|put]_bpf_permission() Song Liu
2019-06-25 20:51 ` Stanislav Fomichev [this message]
2019-06-25 21:00   ` [PATCH bpf-next 0/4] sys_bpf() access control via /dev/bpf Alexei Starovoitov
2019-06-25 21:19     ` Stanislav Fomichev
2019-06-25 22:47       ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190625205155.GD10487@mini-arch \
    --to=sdf@fomichev.me \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).