[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77354A95-4107-41A7-8936-D144F01C3CA4@fb.com>
Date: Sat, 27 Jul 2019 18:20:17 +0000
From: Song Liu <songliubraving@...com>
To: Andy Lutomirski <luto@...capital.net>
CC: Andy Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>,
"linux-security@...r.kernel.org" <linux-security@...r.kernel.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <Kernel-team@...com>,
Lorenz Bauer <lmb@...udflare.com>,
Jann Horn <jannh@...gle.com>,
Greg KH <gregkh@...uxfoundation.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
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).
Does this make sense? (Or did I misunderstand anything?)
Thanks,
Song
Powered by blists - more mailing lists