Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

Hi Oleg, On Thu, Jun 04, 2015 at 08:31:49PM +0200, Oleg Nesterov wrote: On 06/03, Tycho Andersen wrote: @@ -556,6 +557,11 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data) if (data ~(unsigned long)PTRACE_O_MASK) return -EINVAL; +#ifdef

[PATCH v2] seccomp: add ptrace options for suspend/resume

. This means that as soon as the tracer detaches/dies, seccomp is re-enabled and as a corrollary that one can not disable seccomp across PTRACE_ATTACHs. Signed-off-by: Tycho Andersen tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l...@amacapital.net CC

Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

On Thu, Jun 04, 2015 at 09:44:36AM -0700, Kees Cook wrote: On Wed, Jun 3, 2015 at 3:09 PM, Tycho Andersen tycho.ander...@canonical.com wrote: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. One of the things CRIU does while dumping tasks

Re: [PATCH v3] seccomp: add ptrace options for suspend/resume

On Fri, Jun 05, 2015 at 11:52:08PM +0200, Oleg Nesterov wrote: Tycho, I hate myself, but I have another nit ;) again, it is not that I think you should updtate the patch, just fyi... No worries :) On 06/05, Tycho Andersen wrote: --- a/include/linux/seccomp.h +++ b/include/linux

[PATCH v3] seccomp: add ptrace options for suspend/resume

-off-by: Tycho Andersen tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l...@amacapital.net CC: Will Drewry w...@chromium.org CC: Roland McGrath rol...@hack.frob.com CC: Oleg Nesterov o...@redhat.com CC: Pavel Emelyanov xe...@parallels.com CC: Serge E. Hallyn

Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

On Fri, Jun 05, 2015 at 11:16:50PM +0200, Oleg Nesterov wrote: Hi Tycho, On 06/04, Tycho Andersen wrote: On Thu, Jun 04, 2015 at 08:31:49PM +0200, Oleg Nesterov wrote: Also. Suppose that the tracer sets SUSPEND_SECCOMP and then drops CAP_SYS_ADMIN. After that it can't set or clear

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Tue, Jun 02, 2015 at 12:27:42PM -0700, Andy Lutomirski wrote: It might be worth changing the check to verify that the task trying to suspect seccomp isn't itself subject to seccomp. That should get most of the safety. Sounds good, I'll make the change. Tycho -- To unsubscribe from this

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Tue, Jun 02, 2015 at 08:28:29PM +0200, Oleg Nesterov wrote: On 06/01, Tycho Andersen wrote: --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -25,6 +25,9 @@ struct seccomp_filter; struct seccomp { int mode; struct seccomp_filter *filter; +#ifdef

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Tue, Jun 02, 2015 at 08:48:48PM +0200, Oleg Nesterov wrote: On 06/02, Tycho Andersen wrote: Do we need to re-enable seccomp if a tracer detaches unexpectedly. CRIU can be killed and we should try to not affect the task state even in this case. Yes, I think Pavel's suggestion

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

Hi Oleg, On Wed, Jun 03, 2015 at 06:41:21PM +0200, Oleg Nesterov wrote: On 06/03, Tycho Andersen wrote: On Tue, Jun 02, 2015 at 08:28:29PM +0200, Oleg Nesterov wrote: On 06/01, Tycho Andersen wrote: --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -25,6 +25,9

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Wed, Jun 03, 2015 at 06:54:51PM +0200, Oleg Nesterov wrote: On 06/03, Tycho Andersen wrote: On Tue, Jun 02, 2015 at 08:48:48PM +0200, Oleg Nesterov wrote: Otherwise, if we use PTRACE_O_ instead, it goes away automatically if the tracer dies or does PTRACE_DETACH. IIRC the flag

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Wed, Jun 03, 2015 at 06:54:51PM +0200, Oleg Nesterov wrote: On 06/03, Tycho Andersen wrote: On Tue, Jun 02, 2015 at 08:48:48PM +0200, Oleg Nesterov wrote: Otherwise, if we use PTRACE_O_ instead, it goes away automatically if the tracer dies or does PTRACE_DETACH. IIRC the flag

Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

Hi Kees, Andy, On Fri, Jun 05, 2015 at 11:16:50PM +0200, Oleg Nesterov wrote: Hi Tycho, On 06/04, Tycho Andersen wrote: +#ifdef CONFIG_CHECKPOINT_RESTORE +bool may_suspend_seccomp(void) +{ + if (!capable(CAP_SYS_ADMIN)) + return false

Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

On Tue, Jun 09, 2015 at 02:45:49PM -0700, Kees Cook wrote: On Tue, Jun 9, 2015 at 2:22 PM, Tycho Andersen tycho.ander...@canonical.com wrote: Hi Kees, Andy, On Fri, Jun 05, 2015 at 11:16:50PM +0200, Oleg Nesterov wrote: Hi Tycho, On 06/04, Tycho Andersen wrote: +#ifdef

Re: [PATCH v2] seccomp: add ptrace options for suspend/resume

On Tue, Jun 09, 2015 at 03:06:07PM -0700, Kees Cook wrote: On Tue, Jun 9, 2015 at 2:52 PM, Tycho Andersen tycho.ander...@canonical.com wrote: On Tue, Jun 09, 2015 at 02:45:49PM -0700, Kees Cook wrote: On Tue, Jun 9, 2015 at 2:22 PM, Tycho Andersen tycho.ander...@canonical.com wrote: Hi

[PATCH v4] seccomp: add ptrace options for suspend/resume

changes: * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace directly Signed-off-by: Tycho Andersen tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l...@amacapital.net CC: Will Drewry w...@chromium.org CC: Roland McGrath rol

Re: [PATCH v4] seccomp: add ptrace options for suspend/resume

On Wed, Jun 10, 2015 at 01:33:21PM -0700, Kees Cook wrote: And if I've convinced Andy to be okay with this patch, consider v4: Acked-by: Kees Cook keesc...@chromium.org Thanks, I'm happy to send a v5 with checking seccomp (and -ptrace PT_SUSPEND_SECCOMP) if you'd feel better with that,

Re: [kees:seccomp/tip 2/2] kernel/ptrace.c:567:3: note: in expansion of macro 'if'

On Mon, Jun 15, 2015 at 03:25:39PM -0700, Kees Cook wrote: Looks like dead-code elimination happens after structures are accessed, so this needs to use the accessor. Sorry I missed this earlier! Whoops, thanks! Tycho -- To unsubscribe from this list: send the line unsubscribe linux-kernel in

Re: [PATCH v5] seccomp: add ptrace options for suspend/resume

...@redhat.com wrote: On 06/13, Tycho Andersen wrote: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. So just in case, I am fine with this version. Should I add your Ack? Though I really like the idea of a Fine-with-this: tag. ;) Yes

[PATCH v5] seccomp: add ptrace options for suspend/resume

changes: * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace directly v5 changes: * check that seccomp is not enabled (or suspended) on the tracer Signed-off-by: Tycho Andersen tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l

Re: [PATCH v4] seccomp: add ptrace options for suspend/resume

: On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov o...@redhat.com wrote: On 06/09, Andy Lutomirski wrote: On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data) if (data ~(unsigned long

Re: [PATCH v4] seccomp: add ptrace options for suspend/resume

Hi Andy, On Tue, Jun 09, 2015 at 06:08:42PM -0700, Andy Lutomirski wrote: + if (unlikely(data PTRACE_O_SUSPEND_SECCOMP)) { + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) || + !config_enabled(CONFIG_SECCOMP)) + return -EINVAL;

[PATCH] seccomp: add ptrace commands for suspend/resume

be successfully dumped (and restored). Signed-off-by: Tycho Andersen tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l...@amacapital.net CC: Will Drewry w...@chromium.org CC: Roland McGrath rol...@hack.frob.com CC: Oleg Nesterov o...@redhat.com CC: Pavel

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote: On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen tycho.ander...@canonical.com wrote: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. One of the things CRIU does while dumping

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote: On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen tycho.ander...@canonical.com wrote: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. One of the things CRIU does while dumping

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Mon, Jun 01, 2015 at 12:51:12PM -0700, Andy Lutomirski wrote: On Mon, Jun 1, 2015 at 12:47 PM, Tycho Andersen tycho.ander...@canonical.com wrote: On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote: On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen tycho.ander...@canonical.com

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Tue, Jun 02, 2015 at 12:36:16PM +0300, Andrey Wagin wrote: 2015-06-01 22:28 GMT+03:00 Tycho Andersen tycho.ander...@canonical.com: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. One of the things CRIU does while dumping tasks is inject

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

Hi Andy, On Mon, Jun 01, 2015 at 02:12:33PM -0600, Tycho Andersen wrote: On Mon, Jun 01, 2015 at 12:51:12PM -0700, Andy Lutomirski wrote: On Mon, Jun 1, 2015 at 12:47 PM, Tycho Andersen tycho.ander...@canonical.com wrote: On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

Hi Oleg, On Wed, Oct 21, 2015 at 08:51:46PM +0200, Oleg Nesterov wrote: > On 10/20, Tycho Andersen wrote: > > > > Hi Kees, Oleg, > > > > On Tue, Oct 20, 2015 at 10:20:24PM +0200, Oleg Nesterov wrote: > > > > > > No, you can't do copy_t

[PATCH net-next] seccomp, ptrace: add support for dumping seccomp filters

spinlocks v5: * add another condition to WARN_ON v6: * rebase on net-next Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> Acked-by: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> Reviewed-by: Oleg Nesterov <o...@redhat.com> CC: And

seccomp c/r patch

Hi all, Here is a patch that we'd like to go via net-next, as it depends on previous changes in that tree. Thanks, Tycho -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

ctually, since this depends on changes in net, could this get pulled > in from that direction? > > Acked-by: Kees Cook <keesc...@chromium.org> Can we get the attached patch into net-next? Thanks, Tycho >From 5d9be66e4f48e0882a5546376380147f2f711bec Mon Sep 17 00:00:00 2001 From:

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

unlikely"? > > Btw, the conditions inside the WARN_ON() macro would already resolve > to unlikely(). Here's an updated patch with the !filter as well. Thanks, Tycho >From f37256a6f5e9e975943024ec0a26796a48521492 Mon Sep 17 00:00:00 2001 From: Tycho Andersen <tycho.ander.

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

Hi Oleg, On Wed, Oct 21, 2015 at 11:07:56PM +0200, Oleg Nesterov wrote: > On 10/21, Tycho Andersen wrote: > > > > Hi Oleg, > > > > On Wed, Oct 21, 2015 at 08:51:46PM +0200, Oleg Nesterov wrote: > > > > + > > > > + if (WARN_ON(count

Re: [PATCH v6] seccomp, ptrace: add support for dumping seccomp filters

On Wed, Oct 07, 2015 at 03:18:09PM -0700, Kees Cook wrote: > On Wed, Oct 7, 2015 at 2:46 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > This patch adds support for dumping a process' (classic BPF) seccomp > > filters via ptrace. > > > > PTRACE_

Re: [PATCH v7] seccomp, ptrace: add support for dumping seccomp filters

Hi Oleg, On Tue, Oct 20, 2015 at 08:00:24PM +0200, Oleg Nesterov wrote: > Sorry for delay... No problem, thanks for the review. > On 10/13, Tycho Andersen wrote: > > > > --- a/include/uapi/linux/ptrace.h > > +++ b/include/uapi/linux/ptrace.h > > @@ -23,6 +23,8 @@ &

v8 of seccomp filter c/r

Hi all, Here's v8 of the seccomp filter c/r stuff, which has some minor changes dropping a lock and changing a constant. Note that this is now based on http://patchwork.ozlabs.org/patch/525492/ and will need to be built with that patch applied. This gets rid of two incorrect patches in a

[PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

it an unsigned long to match ptrace * count "down" the tree instead of "up" when passing a filter offset v3: * don't take the current task's lock for inspecting its seccomp mode * use a 0x42** constant for the ptrace command value Signed-off-by: Tycho Andersen <tycho.and

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

On Tue, Oct 20, 2015 at 01:26:01PM -0700, Kees Cook wrote: > On Tue, Oct 20, 2015 at 1:20 PM, Oleg Nesterov wrote: > > > > Oh wait, I didn't notice this when I looked at v7. > > > > No, you can't do copy_to_user() from atomic context. You need to pin this > > filter, drop the

Re: [PATCH v8] seccomp, ptrace: add support for dumping seccomp filters

cho >From 5be84ece99312304df2a61f727355ffd3fc604da Mon Sep 17 00:00:00 2001 From: Tycho Andersen <tycho.ander...@canonical.com> Date: Fri, 2 Oct 2015 18:49:43 -0600 Subject: [PATCH v9] seccomp, ptrace: add support for dumping seccomp filters This patch adds support for dumping a process' (classic BPF) seccomp

Re: [PATCH v6] seccomp, ptrace: add support for dumping seccomp filters

On Wed, Oct 07, 2015 at 12:34:26PM +0200, Daniel Borkmann wrote: > On 10/07/2015 12:25 PM, Daniel Borkmann wrote: > >On 10/07/2015 11:46 AM, Tycho Andersen wrote: > >>This patch adds support for dumping a process' (classic BPF) seccomp > >>filters via ptrace. > &g

v6 of seccomp filter c/r

Hi all, Here's v6 of the seccomp filter c/r stuff. I've dropped the concept of a seccomp fd entirely, in favor of just dumping the bpf data. This doesn't allow us to restore correctly in all cases, though, as noted in the patch notes. Note that this is now based on

[PATCH v6] seccomp, ptrace: add support for dumping seccomp filters

confuse users of this interface. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomirski <l...@amacapital.net> CC: Pavel Emelyanov <

Re: [PATCH v6] seccomp, ptrace: add support for dumping seccomp filters

Hi Daniel, On Wed, Oct 07, 2015 at 12:25:39PM +0200, Daniel Borkmann wrote: > On 10/07/2015 11:46 AM, Tycho Andersen wrote: > >+ > >+#if defined(CONFIG_SECCOMP_FILTER) && defined(CONFIG_CHECKPOINT_RESTORE) > >+extern long seccomp_get_filter(str

v7 of seccomp filter c/r

Hi all, Here's v7 of the seccomp filter c/r stuff. The biggest change is counting down the seccomp tree instead of up for the index, although there are some other small changes in the notes as well. Note that this is now based on http://patchwork.ozlabs.org/patch/525492/ and will need to be

[PATCH v7] seccomp, ptrace: add support for dumping seccomp filters

it an unsigned long to match ptrace * count "down" the tree instead of "up" when passing a filter offset Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov &l

Re: eBPF / seccomp globals?

Hi all, On Thu, Sep 03, 2015 at 08:17:05PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 01:01:20AM +, Michael Tirado wrote: > > Hiyall, > > > > I have created a seccomp white list filter for a program that launches > > other less trustworthy programs. It's working great so

[PATCH 1/6] ebpf: add a seccomp program type

interesting features (notably, maps) of eBPF. However, the primary motivation for this patchset is to enable checkpoint/restore for seccomp filters later in the series, to this limited feature set is ok for now. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook

c/r of seccomp filters via underlying eBPF

Hi all, Here is a set that enables checkpoint restore of the underlying eBPF programs that power seccomp filters via the API we discussed several months ago. A few notes: * We expose prog_id in the ebpf dump as the pointer to the ebpf program in kernel memory, since this is unique. I'm not

[PATCH 6/6] ebpf: allow BPF_REG_X in src_reg conditional jumps

t;code); } but here, we enforce that the src_reg == BPF_REG_0. We should also allow BPF_REG_X since that's what the converter generates; this enables us to load eBPF programs that were generated by the converter. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <

[PATCH 2/6] seccomp: make underlying bpf ref counted as well

. Additionally, we mark classic converted seccomp filters as seccomp eBPF programs, since they are a subset of what is supported in seccomp eBPF. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC

[PATCH 3/6] ebpf: add a way to dump an eBPF program

seccomp filters were inherited from each other and clone the filter tree accordingly. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomir

[PATCH 4/6] seccomp: add a way to access filters via bpf fds

_PROG_DUMP) to dump the actual program at each step. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomirski <l...@amacapital.net>

[PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd

to it which seems impolite. Right now we cast the pointer (and force the user to cast it), which generates ugly warnings. I'm not sure what the right answer is here. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w.

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Fri, Sep 04, 2015 at 01:58:25PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 01:50:55PM -0700, Kees Cook wrote: > > On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen > > <tycho.ander...@canonical.com> wrote: > > > On Fri, Sep 04, 2015 at 01:

Re: [PATCH 1/6] ebpf: add a seccomp program type

On Fri, Sep 04, 2015 at 01:34:12PM -0700, Kees Cook wrote: > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > +static const struct bpf_func_proto * > > +seccomp_func_proto(enum bpf_func_id func_id) > > +{ > > +

Re: [PATCH 4/6] seccomp: add a way to access filters via bpf fds

On Fri, Sep 04, 2015 at 01:29:49PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 01:26:42PM -0700, Kees Cook wrote: > > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > > <tycho.ander...@canonical.com> wrote: > > > This patch adds a way for a process

Re: [PATCH 1/6] ebpf: add a seccomp program type

On Fri, Sep 04, 2015 at 01:17:47PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 10:04:19AM -0600, Tycho Andersen wrote: > > seccomp uses eBPF as its underlying storage and execution format, and eBPF > > has features that seccomp would like to make use of in the future.

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > This commit adds a way to dump eBPF programs. The initial implementation > > doesn't support maps, and therefore only all

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

Hi Alexei, On Fri, Sep 04, 2015 at 01:27:05PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 10:04:21AM -0600, Tycho Andersen wrote: > > This commit adds a way to dump eBPF programs. The initial implementation > > doesn't support maps, and therefore only allows dumpi

Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd

On Sat, Sep 05, 2015 at 09:13:02AM +0200, Michael Kerrisk (man-pages) wrote: > On 09/04/2015 10:41 PM, Kees Cook wrote: > > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > > <tycho.ander...@canonical.com> wrote: > >> This is the final bit needed to support secco

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: > On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote: > >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho

Re: [PATCH 6/6] ebpf: allow BPF_REG_X in src_reg conditional jumps

Hi Alexei, On Fri, Sep 04, 2015 at 02:06:19PM -0700, Alexei Starovoitov wrote: > On Fri, Sep 04, 2015 at 10:04:24AM -0600, Tycho Andersen wrote: > > The classic converter generates conditional jumps with: > > > > if (BPF_SRC(fp->code) == BPF_K && (int) fp->

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Fri, Sep 04, 2015 at 04:08:53PM -0700, Andy Lutomirski wrote: > On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote: > >> On Fri, Sep 4, 2015 at 1:45 PM, Tycho

Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd

On Wed, Sep 09, 2015 at 08:14:04AM -0700, Alexei Starovoitov wrote: > On Wed, Sep 09, 2015 at 08:47:24AM -0600, Tycho Andersen wrote: > > On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote: > > > > > > Yeah, bpf's union looks good. Let's add a "command&quo

Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd

On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote: > > Yeah, bpf's union looks good. Let's add a "command" flag, though: > > seccomp(SECCOMP_MODE_FILTER_EBPF, int cmd, union, size); > > And this cmd could be ADD_FD or something? > > How's that look? I think we can drop the size (using

Re: [PATCH 1/6] ebpf: add a seccomp program type

On Fri, Sep 04, 2015 at 02:08:37PM -0700, Kees Cook wrote: > On Fri, Sep 4, 2015 at 2:06 PM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Fri, Sep 04, 2015 at 01:34:12PM -0700, Kees Cook wrote: > >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen > &g

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Fri, Sep 04, 2015 at 06:27:27PM -0600, Tycho Andersen wrote: > On Fri, Sep 04, 2015 at 04:08:53PM -0700, Andy Lutomirski wrote: > > On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen > > <tycho.ander...@canonical.com> wrote: > > > On Fri, Sep 04, 2015 at 02:48:03P

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Wed, Sep 09, 2015 at 04:44:24PM -0700, Andy Lutomirski wrote: > On Wed, Sep 9, 2015 at 3:34 PM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > > > Here's a thought, > > > > The set I'm currently proposing effectively separates the ref-counting &

[PATCH v2 3/5] ebpf: add a way to dump an eBPF program

This commit adds a way to dump eBPF programs. The initial implementation doesn't support maps, and therefore only allows dumping seccomp ebpf programs which themselves don't currently support maps. v2: don't export a prog_id for the filter Signed-off-by: Tycho Andersen <tycho.an

[PATCH v2 5/5] seccomp: add a way to attach a filter via eBPF fd

similar to that of bpf(), although the size is explicit in the struct to avoid changing the signature of seccomp(). v2: Don't abuse seccomp's third argument; use a separate command and a pointer to a structure instead. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kee

[PATCH v2 4/5] seccomp: add a way to access filters via bpf fds

_PROG_DUMP) to dump the actual program at each step. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomirski <l...@amacapital.net>

v2 of seccomp filter c/r patches

Hi all, Here is v2 of the seccomp filter c/r set. The patch notes have individual changes from the last series, but there are two points not noted: * The series still does not allow us to correctly restore state for programs that will use SECCOMP_FILTER_FLAG_TSYNC in the future. Given that we

[PATCH v2 1/5] ebpf: add a seccomp program type

of superfluous seccomp_convert_ctx_access Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomirski <l...@amacapital.net> CC: Pavel Emelyanov <

[PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

. Additionally, we mark classic converted seccomp filters as seccomp eBPF programs, since they are a subset of what is supported in seccomp eBPF. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC

Re: [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

Hi Daniel, On Fri, Sep 11, 2015 at 08:28:19PM +0200, Daniel Borkmann wrote: > I think due to the given insns restrictions on classic seccomp, this > could work for "most cases" (see below) for the time being until pointer > sanitation is resolved and that seccomp-only restriction from the dump >

Re: [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

On Mon, Sep 14, 2015 at 06:48:43PM +0200, Daniel Borkmann wrote: > On 09/14/2015 06:00 PM, Tycho Andersen wrote: > >On Fri, Sep 11, 2015 at 08:28:19PM +0200, Daniel Borkmann wrote: > >>I think due to the given insns restrictions on classic seccomp, this > >>could work

Re: [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

On Fri, Sep 11, 2015 at 06:03:59PM +0200, Daniel Borkmann wrote: > On 09/11/2015 04:44 PM, Tycho Andersen wrote: > >On Fri, Sep 11, 2015 at 03:02:36PM +0200, Daniel Borkmann wrote: > >>On 09/11/2015 02:20 AM, Tycho Andersen wrote: > >>>In the next patch, we'r

Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds

On Fri, Sep 11, 2015 at 09:20:55AM -0700, Andy Lutomirski wrote: > On Sep 10, 2015 5:22 PM, "Tycho Andersen" <tycho.ander...@canonical.com> > wrote: > > > > This patch adds a way for a process that is "real root" to access the > > seccomp

Re: v2 of seccomp filter c/r patches

On Fri, Sep 11, 2015 at 10:00:22AM -0700, Andy Lutomirski wrote: > On Fri, Sep 11, 2015 at 9:30 AM, Andy Lutomirski <l...@amacapital.net> wrote: > > On Sep 10, 2015 5:22 PM, "Tycho Andersen" <tycho.ander...@canonical.com> > > wrote: > >> > >>

Re: v2 of seccomp filter c/r patches

Hi Andy, On Tue, Sep 15, 2015 at 11:13:51AM -0700, Andy Lutomirski wrote: > On Tue, Sep 15, 2015 at 9:07 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > Hi Andy, > > > > On Mon, Sep 14, 2015 at 10:52:46AM -0700, Andy Lutomirski wrote: > >

Re: v2 of seccomp filter c/r patches

Hi Andy, On Mon, Sep 14, 2015 at 10:52:46AM -0700, Andy Lutomirski wrote: > > I'm not sure I entirely like this solution... Ok. Since we also aren't going to do all the eBPF stuff now, how about something that looks like this: struct seccomp_layer { unsigned int size; unsigned int type; /*

Re: v2 of seccomp filter c/r patches

Hi Andy, On Tue, Sep 15, 2015 at 01:01:23PM -0700, Andy Lutomirski wrote: > On Tue, Sep 15, 2015 at 11:26 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > Hi Andy, > > > > On Tue, Sep 15, 2015 at 11:13:51AM -0700, Andy Lutomirski wrote: > >>

Re: [PATCH 3/6] ebpf: add a way to dump an eBPF program

On Wed, Sep 09, 2015 at 05:44:06PM -0700, Andy Lutomirski wrote: > On Wed, Sep 9, 2015 at 5:13 PM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Wed, Sep 09, 2015 at 04:44:24PM -0700, Andy Lutomirski wrote: > >> On Wed, Sep 9, 2015 at 3:34 PM, Tycho

Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds

On Fri, Sep 11, 2015 at 01:47:38PM +0200, Daniel Borkmann wrote: > 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_SEC

Re: [PATCH v2 5/5] seccomp: add a way to attach a filter via eBPF fd

On Fri, Sep 11, 2015 at 02:37:59PM +0200, Daniel Borkmann wrote: > On 09/11/2015 02:21 AM, Tycho Andersen wrote: > >This is the final bit needed to support seccomp filters created via the bpf > >syscall. The patch adds a new seccomp operation SECCOMP_MODE_FILTER_EBPF, > >wh

Re: [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well

On Fri, Sep 11, 2015 at 03:02:36PM +0200, Daniel Borkmann wrote: > On 09/11/2015 02:20 AM, Tycho Andersen wrote: > >In the next patch, we're going to add a way to access the underlying > >filters via bpf fds. This means that we need to ref-count both the > >struct s

Re: [PATCH v2 3/5] ebpf: add a way to dump an eBPF program

On Fri, Sep 11, 2015 at 03:39:14PM +0200, Daniel Borkmann wrote: > On 09/11/2015 02:21 AM, Tycho Andersen wrote: > >This commit adds a way to dump eBPF programs. The initial implementation > >doesn't support maps, and therefore only allows dumping seccomp ebpf > >programs w

Re: [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds

Hi Michael, On Fri, Sep 11, 2015 at 02:08:50PM +0200, Michael Kerrisk (man-pages) wrote: > HI Tycho > > On 11 September 2015 at 02:21, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > This patch adds a way for a process that is "real root" to access

Re: [PATCH v2 3/5] ebpf: add a way to dump an eBPF program

On Thu, Sep 10, 2015 at 07:29:42PM -0700, Alexei Starovoitov wrote: > On Thu, Sep 10, 2015 at 06:21:00PM -0600, Tycho Andersen wrote: > > +static int bpf_prog_dump(union bpf_attr *attr, union bpf_attr __user > > *uattr) > > +{ > > + int ufd = attr->prog_fd; &

checkpoint/restore of seccomp filters v3

Hi all, Here's a re-worked set for c/r of seccomp filters which keeps around the original bpf program passed to the kernel instead of trying to dump the ebpf version. There are various comments/questions in the individual patch notes. I'm not sure this needs to go via net-next any more, as the

[PATCH v3 1/5] seccomp: save the original filter

In order to implement checkpoint of seccomp filters, we need to keep track of the original filter as the user gave it to us. Since we're doing this, we need to also use bpf_prog_destroy to free the struct bpf_brogs so we don't leak this memory. Signed-off-by: Tycho Andersen <tycho.an

Re: [PATCH v3 4/5] kcmp: add KCMP_FILE_PRIVATE_DATA

On Wed, Sep 30, 2015 at 11:25:41AM -0700, Andy Lutomirski wrote: > On Wed, Sep 30, 2015 at 11:13 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > This command allows comparing the underling private data of two fds. This > > is useful e.g. to find out if a sec

[PATCH v3 2/5] seccomp: add the concept of a seccomp filter FD

filter that another task has installed. One option to work around this is to keep a bit on struct seccomp_filter to allow each filter to have its parent set exactly once. (This would still allow you to install a filter multiple times, as long as the parent was the same in each case.) Signed-of

[PATCH v3 3/5] seccomp: add a ptrace command to get seccomp filter fds

TER implies that there is at least one filter. If there is a more appropriate errno (ESRCH collides as well with ptrace) to give here that may be better. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium

[PATCH v3 4/5] kcmp: add KCMP_FILE_PRIVATE_DATA

This command allows comparing the underling private data of two fds. This is useful e.g. to find out if a seccomp filter is inherited, since struct seccomp_filter are unique across tasks and are the private_data seccomp fds. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC

[PATCH v3 5/5] bpf: save the program the user actually supplied

are not allowed by bpf_check_classic. Signed-off-by: Tycho Andersen <tycho.ander...@canonical.com> CC: Kees Cook <keesc...@chromium.org> CC: Will Drewry <w...@chromium.org> CC: Oleg Nesterov <o...@redhat.com> CC: Andy Lutomirski <l...@amacapital.net> CC: Pavel Emelyanov <

Re: [PATCH v3 4/5] kcmp: add KCMP_FILE_PRIVATE_DATA

On Wed, Sep 30, 2015 at 11:47:05AM -0700, Andy Lutomirski wrote: > On Wed, Sep 30, 2015 at 11:41 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Wed, Sep 30, 2015 at 11:25:41AM -0700, Andy Lutomirski wrote: > >> On Wed, Sep 30, 2015 at 11:13 AM, Tycho

Re: [PATCH v3 2/5] seccomp: add the concept of a seccomp filter FD

On Wed, Sep 30, 2015 at 11:27:34AM -0700, Andy Lutomirski wrote: > On Wed, Sep 30, 2015 at 11:13 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > This patch introduces the concept of a seccomp fd, with a similar interface > > and usage to ebpf fds. Initially,

Re: [PATCH v3 4/5] kcmp: add KCMP_FILE_PRIVATE_DATA

On Wed, Sep 30, 2015 at 11:56:25AM -0700, Andy Lutomirski wrote: > On Wed, Sep 30, 2015 at 11:55 AM, Tycho Andersen > <tycho.ander...@canonical.com> wrote: > > On Wed, Sep 30, 2015 at 11:47:05AM -0700, Andy Lutomirski wrote: > >> On Wed, Sep 30, 2015 at 11:41 AM, Tycho

  1   2   3   4   5   6   7   8   9   10   >