From: Song Liu <songliubraving@fb.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>,
Kees Cook <keescook@chromium.org>,
"linux-security@vger.kernel.org" <linux-security@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>,
Lorenz Bauer <lmb@cloudflare.com>, Jann Horn <jannh@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
Date: Tue, 30 Jul 2019 05:07:25 +0000 [thread overview]
Message-ID: <369476A8-4CE1-43DA-9239-06437C0384C7@fb.com> (raw)
In-Reply-To: <77354A95-4107-41A7-8936-D144F01C3CA4@fb.com>
Hi Andy,
> On Jul 27, 2019, at 11:20 AM, Song Liu <songliubraving@fb.com> wrote:
>
> Hi Andy,
>
>>>>>
>>>>
>>>> Well, yes. sys_bpf() is pretty powerful.
>>>>
>>>> The goal of /dev/bpf is to enable special users to call sys_bpf(). In
>>>> the meanwhile, such users should not take down the whole system easily
>>>> by accident, e.g., with rm -rf /.
>>>
>>> That’s easy, though — bpftool could learn to read /etc/bpfusers before allowing ruid != 0.
>>
>> This is a great idea! fscaps + /etc/bpfusers should do the trick.
>
> After some discussions and more thinking on this, I have some concerns
> with the user space only approach.
>
> IIUC, your proposal for user space only approach is like:
>
> 1. bpftool (and other tools) check /etc/bpfusers and only do
> setuid for allowed users:
>
> int main()
> {
> if (/* uid in /etc/bpfusers */)
> setuid(0);
> sys_bpf(...);
> }
>
> 2. bpftool (and other tools) is installed with CAP_SETUID:
>
> setcap cap_setuid=e+p /bin/bpftool
>
> 3. sys admin maintains proper /etc/bpfusers.
>
> This approach is not ideal, because we need to trust the tool to give
> it CAP_SETUID. A hacked tool could easily bypass /etc/bpfusers check
> or use other root only sys calls after setuid(0).
>
I would like more comments on this.
Currently, bpf permission is more or less "root or nothing", which we
would like to change.
The short term goal is to separate bpf from root, in other words, it is
"all or nothing". Special user space utilities, such as systemd, would
benefit from this. Once this is implemented, systemd can call sys_bpf()
when it is not running as root.
In longer term, it may be useful to provide finer grain permission of
sys_bpf(). For example, sys_bpf() should be aware of containers; and
user may only have access to certain bpf maps. Let's call this
"fine grain" capability.
Since we are seeing new use cases every year, we will need many
iterations to implement the fine grain permission. I think we need an
API that is flexible enough to cover different types of permission
control.
For example, bpf_with_cap() can be flexible:
bpf_with_cap(cmd, attr, size, perm_fd);
We can get different types of permission via different combinations of
arguments:
A perm_fd to /dev/bpf gives access to all sys_bpf() commands, so
this is "all or nothing" permission.
A perm_fd to /sys/fs/cgroup/.../bpf.xxx would only allow some
commands to this specific cgroup.
Alexei raised another idea in offline discussions: instead of adding
bpf_with_cap(), we add a command LOAD_PERM_FD, which enables special
permission for the _next_ sys_bpf() from current task:
bpf(LOAD_PERM_FD, perm_fd);
/* the next sys_bpf() uses permission from perm_fd */
bpf(cmd, attr, size);
This is equivalent to bpf_with_cap(cmd, attr, size, perm_fd), but
doesn't require the new sys call.
For both these ideas, we will start with /dev/bpf. As we grow the
fine grain permission control, fewer users/processes will need access
to /dev/bpf.
Please let us know your thought on this. Would this make /dev/bpf
more reasonable? :-)
A few notes for previous discussions:
1. User space only approach doesn't work, even for "all or nothing"
permission control. I expanded the discussion in the previous
email. Please let me know if I missed anything there.
2. Permission control only at BPF_PROG_ATTACH time is not sufficient.
We need permission control during BPF_PROG_LOAD, e.g., is_priv in
the verifier.
Thanks,
Song
next prev parent reply other threads:[~2019-07-30 5:08 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 20:19 [PATCH v2 bpf-next 0/4] sys_bpf() access control via /dev/bpf Song Liu
2019-06-27 20:19 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access " Song Liu
2019-06-27 23:40 ` Andy Lutomirski
2019-06-27 23:42 ` Andy Lutomirski
2019-06-28 10:28 ` Christian Brauner
2019-06-28 9:05 ` Lorenz Bauer
2019-06-28 19:04 ` Song Liu
2019-06-30 0:12 ` Andy Lutomirski
2019-07-01 9:03 ` Song Liu
2019-07-02 1:59 ` Andy Lutomirski
2019-07-02 18:24 ` Kees Cook
2019-07-02 21:32 ` Andy Lutomirski
2019-07-02 23:48 ` Song Liu
2019-07-22 20:53 ` Song Liu
2019-07-23 10:45 ` Lorenz Bauer
2019-07-23 15:11 ` Andy Lutomirski
2019-07-23 22:56 ` Song Liu
2019-07-24 1:40 ` Andy Lutomirski
2019-07-24 6:30 ` Song Liu
2019-07-27 18:20 ` Song Liu
2019-07-30 5:07 ` Song Liu [this message]
2019-07-30 20:24 ` Andy Lutomirski
2019-07-31 8:10 ` Song Liu
2019-07-31 19:09 ` Andy Lutomirski
2019-08-02 7:21 ` Song Liu
2019-08-04 22:16 ` Andy Lutomirski
2019-08-05 0:08 ` Andy Lutomirski
2019-08-05 5:47 ` Andy Lutomirski
2019-08-05 7:36 ` Song Liu
2019-08-05 17:23 ` Andy Lutomirski
2019-08-05 19:21 ` Alexei Starovoitov
2019-08-05 21:25 ` Andy Lutomirski
2019-08-05 22:21 ` Andy Lutomirski
2019-08-06 1:11 ` Alexei Starovoitov
2019-08-07 5:24 ` Andy Lutomirski
2019-08-07 9:03 ` Lorenz Bauer
2019-08-07 13:52 ` Andy Lutomirski
2019-08-13 21:58 ` Alexei Starovoitov
2019-08-13 22:26 ` Daniel Colascione
2019-08-13 23:24 ` Andy Lutomirski
2019-08-13 23:06 ` Andy Lutomirski
2019-08-14 0:57 ` Alexei Starovoitov
2019-08-14 17:51 ` Andy Lutomirski
2019-08-14 22:05 ` Alexei Starovoitov
2019-08-14 22:30 ` Andy Lutomirski
2019-08-14 23:33 ` Alexei Starovoitov
2019-08-14 23:59 ` Andy Lutomirski
2019-08-15 0:36 ` Alexei Starovoitov
2019-08-15 11:24 ` Jordan Glover
2019-08-15 17:28 ` Alexei Starovoitov
2019-08-15 18:36 ` Andy Lutomirski
2019-08-15 23:08 ` Alexei Starovoitov
2019-08-16 9:34 ` Jordan Glover
2019-08-16 9:59 ` Thomas Gleixner
2019-08-16 11:33 ` Jordan Glover
2019-08-16 19:52 ` Alexei Starovoitov
2019-08-16 20:28 ` Thomas Gleixner
2019-08-17 15:02 ` Alexei Starovoitov
2019-08-17 15:44 ` Andy Lutomirski
2019-08-19 9:15 ` Thomas Gleixner
2019-08-19 17:27 ` Alexei Starovoitov
2019-08-19 17:38 ` Andy Lutomirski
2019-08-15 18:43 ` Jordan Glover
2019-08-15 19:46 ` Kees Cook
2019-08-15 23:46 ` Alexei Starovoitov
2019-08-16 0:54 ` Andy Lutomirski
2019-08-16 5:56 ` Song Liu
2019-08-16 21:45 ` Alexei Starovoitov
2019-08-16 22:22 ` Christian Brauner
2019-08-17 15:08 ` Alexei Starovoitov
2019-08-17 15:16 ` Christian Brauner
2019-08-17 15:36 ` Alexei Starovoitov
2019-08-17 15:42 ` Christian Brauner
2019-08-22 14:17 ` Daniel Borkmann
2019-08-22 15:16 ` Andy Lutomirski
2019-08-22 15:17 ` RFC: very rough draft of a bpf permission model Andy Lutomirski
2019-08-22 23:26 ` Alexei Starovoitov
2019-08-23 23:09 ` Andy Lutomirski
2019-08-26 22:36 ` Alexei Starovoitov
2019-08-27 0:05 ` Andy Lutomirski
2019-08-27 0:34 ` Alexei Starovoitov
2019-08-22 22:48 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Alexei Starovoitov
2019-07-30 20:20 ` Andy Lutomirski
2019-07-31 7:44 ` Song Liu
2019-06-28 9:01 ` Lorenz Bauer
2019-06-28 19:10 ` Song Liu
2019-07-01 9:34 ` Lorenz Bauer
2019-07-02 19:22 ` Andrii Nakryiko
2019-07-03 7:28 ` Greg KH
2019-06-27 20:19 ` [PATCH v2 bpf-next 2/4] bpf: sync tools/include/uapi/linux/bpf.h Song Liu
2019-06-27 20:19 ` [PATCH v2 bpf-next 3/4] libbpf: add libbpf_[enable|disable]_sys_bpf() Song Liu
2019-06-27 20:19 ` [PATCH v2 bpf-next 4/4] bpftool: use libbpf_[enable|disable]_sys_bpf() Song Liu
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=369476A8-4CE1-43DA-9239-06437C0384C7@fb.com \
--to=songliubraving@fb.com \
--cc=Kernel-team@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-security@vger.kernel.org \
--cc=lmb@cloudflare.com \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=netdev@vger.kernel.org \
/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).