From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752584AbbIKLrx (ORCPT ); Fri, 11 Sep 2015 07:47:53 -0400 Received: from www62.your-server.de ([213.133.104.62]:57496 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbbIKLru (ORCPT ); Fri, 11 Sep 2015 07:47:50 -0400 Message-ID: <55F2BF5A.8010006@iogearbox.net> Date: Fri, 11 Sep 2015 13:47:38 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tycho Andersen , Kees Cook , Alexei Starovoitov CC: "David S. Miller" , Will Drewry , Oleg Nesterov , Andy Lutomirski , Pavel Emelyanov , "Serge E. Hallyn" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds References: <1441930862-14347-1-git-send-email-tycho.andersen@canonical.com> <1441930862-14347-5-git-send-email-tycho.andersen@canonical.com> In-Reply-To: <1441930862-14347-5-git-send-email-tycho.andersen@canonical.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/11/2015 02:21 AM, Tycho Andersen wrote: > This patch adds a way for a process that is "real root" to access the > seccomp filters of another process. The process first does a > PTRACE_SECCOMP_GET_FILTER_FD to get an fd with that process' seccomp filter > attached, and then iterates on this with PTRACE_SECCOMP_NEXT_FILTER using > bpf(BPF_PROG_DUMP) to dump the actual program at each step. > > Signed-off-by: Tycho Andersen > CC: Kees Cook > CC: Will Drewry > CC: Oleg Nesterov > CC: Andy Lutomirski > CC: Pavel Emelyanov > CC: Serge E. Hallyn > CC: Alexei Starovoitov > CC: Daniel Borkmann [...] > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index 58ae9f4..ac3ed1c 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -506,6 +506,30 @@ struct bpf_prog *bpf_prog_get(u32 ufd) > } > EXPORT_SYMBOL_GPL(bpf_prog_get); > > +int bpf_prog_set(u32 ufd, struct bpf_prog *new) > +{ > + struct fd f; > + struct bpf_prog *prog; > + > + f = fdget(ufd); > + > + prog = get_prog(f); > + if (!IS_ERR(prog) && prog) > + bpf_prog_put(prog); > + > + atomic_inc(&new->aux->refcnt); > + f.file->private_data = new; > + fdput(f); > + return 0; So in case get_prog() fails, and for example f.file is infact NULL, you assign the bpf prog then to ERR_PTR(-EBADF)'s private_data? :( > +} > +EXPORT_SYMBOL_GPL(bpf_prog_set); > + > +int bpf_new_fd(struct bpf_prog *prog, int flags) > +{ > + return anon_inode_getfd("bpf-prog", &bpf_prog_fops, prog, flags); > +} > +EXPORT_SYMBOL_GPL(bpf_new_fd); Any reason why these two need to be exported for modules? Which modules are using them? I think modules should probably not mess with this. If you already name it generic, it would also be good if bpf_new_fd() is used in case of maps that call anon_inode_getfd(), too.