From: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> To: Tycho Andersen <tycho-E0fblnxP3wo@public.gmane.org> Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Linux Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, Akihiro Suda <suda.akihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>, Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Eric W . Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, Christian Brauner <christian.brauner-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>, Tyler Hicks <tyhicks-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> Subject: Re: [RFC 1/3] seccomp: add a return code to trap to userspace Date: Sun, 4 Feb 2018 17:36:33 +0000 [thread overview] Message-ID: <CALCETrWgu5n+SMqrsZQ7MVYPtzs8otuc7hpA5uPH+JNtFrMBkQ@mail.gmail.com> (raw) In-Reply-To: <20180204104946.25559-2-tycho-E0fblnxP3wo@public.gmane.org> On Sun, Feb 4, 2018 at 10:49 AM, Tycho Andersen <tycho-E0fblnxP3wo@public.gmane.org> wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. Neat! > > The motivation for this is primarily for use with containers. For example, > if a container does an init_module(), we obviously don't want to load this > untrusted code, which may be compiled for the wrong version of the kernel > anyway. Instead, we could parse the module image, figure out which module > the container is trying to load and load it on the host. > > As another example, containers cannot mknod(), since this checks > capable(CAP_SYS_ADMIN). However, harmless devices like /dev/null or > /dev/zero should be ok for containers to mknod, but we'd like to avoid hard > coding some whitelist in the kernel. Another example is mount(), which has > many security restrictions for good reason, but configuration or runtime > knowledge could potentially be used to relax these restrictions. > > This patch adds functionality that is already possible via at least two > other means that I know about, both of which involve ptrace(): first, one > could ptrace attach, and then iterate through syscalls via PTRACE_SYSCALL. > Unfortunately this is slow, so a faster version would be to install a > filter that does SECCOMP_RET_TRACE, which triggers a PTRACE_EVENT_SECCOMP. > Since ptrace allows only one tracer, if the container runtime is that > tracer, users inside the container (or outside) trying to debug it will not > be able to use ptrace, which is annoying. It also means that older > distributions based on Upstart cannot boot inside containers using ptrace, > since upstart itself uses ptrace to start services. > > The actual implementation of this is fairly small, although getting the > synchronization right was/is slightly complex. Also worth noting that there > is one race still present: > > 1. a task does a SECCOMP_RET_USER_NOTIF > 2. the userspace handler reads this notification > 3. the task dies > 4. a new task with the same pid starts > 5. this new task does a SECCOMP_RET_USER_NOTIF, gets the same cookie id > that the previous one did > 6. the userspace handler writes a response I'm slightly confused. I thought the id was never reused for a given struct seccomp_filter. (Also, shouldn't the id be u64, not u32?) On very quick reading, I have a question. What happens if a process has two seccomp_filters attached, one of them returns SECCOMP_RET_USER_NOTIF, and the *other* one has a listener?
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: Tycho Andersen <tycho@tycho.ws> Cc: LKML <linux-kernel@vger.kernel.org>, Linux Containers <containers@lists.linux-foundation.org>, Kees Cook <keescook@chromium.org>, Oleg Nesterov <oleg@redhat.com>, "Eric W . Biederman" <ebiederm@xmission.com>, "Serge E . Hallyn" <serge@hallyn.com>, Christian Brauner <christian.brauner@ubuntu.com>, Tyler Hicks <tyhicks@canonical.com>, Akihiro Suda <suda.akihiro@lab.ntt.co.jp> Subject: Re: [RFC 1/3] seccomp: add a return code to trap to userspace Date: Sun, 4 Feb 2018 17:36:33 +0000 [thread overview] Message-ID: <CALCETrWgu5n+SMqrsZQ7MVYPtzs8otuc7hpA5uPH+JNtFrMBkQ@mail.gmail.com> (raw) In-Reply-To: <20180204104946.25559-2-tycho@tycho.ws> On Sun, Feb 4, 2018 at 10:49 AM, Tycho Andersen <tycho@tycho.ws> wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. Neat! > > The motivation for this is primarily for use with containers. For example, > if a container does an init_module(), we obviously don't want to load this > untrusted code, which may be compiled for the wrong version of the kernel > anyway. Instead, we could parse the module image, figure out which module > the container is trying to load and load it on the host. > > As another example, containers cannot mknod(), since this checks > capable(CAP_SYS_ADMIN). However, harmless devices like /dev/null or > /dev/zero should be ok for containers to mknod, but we'd like to avoid hard > coding some whitelist in the kernel. Another example is mount(), which has > many security restrictions for good reason, but configuration or runtime > knowledge could potentially be used to relax these restrictions. > > This patch adds functionality that is already possible via at least two > other means that I know about, both of which involve ptrace(): first, one > could ptrace attach, and then iterate through syscalls via PTRACE_SYSCALL. > Unfortunately this is slow, so a faster version would be to install a > filter that does SECCOMP_RET_TRACE, which triggers a PTRACE_EVENT_SECCOMP. > Since ptrace allows only one tracer, if the container runtime is that > tracer, users inside the container (or outside) trying to debug it will not > be able to use ptrace, which is annoying. It also means that older > distributions based on Upstart cannot boot inside containers using ptrace, > since upstart itself uses ptrace to start services. > > The actual implementation of this is fairly small, although getting the > synchronization right was/is slightly complex. Also worth noting that there > is one race still present: > > 1. a task does a SECCOMP_RET_USER_NOTIF > 2. the userspace handler reads this notification > 3. the task dies > 4. a new task with the same pid starts > 5. this new task does a SECCOMP_RET_USER_NOTIF, gets the same cookie id > that the previous one did > 6. the userspace handler writes a response I'm slightly confused. I thought the id was never reused for a given struct seccomp_filter. (Also, shouldn't the id be u64, not u32?) On very quick reading, I have a question. What happens if a process has two seccomp_filters attached, one of them returns SECCOMP_RET_USER_NOTIF, and the *other* one has a listener?
next prev parent reply other threads:[~2018-02-04 17:36 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-04 10:49 [RFC 0/3] seccomp trap to userspace Tycho Andersen 2018-02-04 10:49 ` [RFC 1/3] seccomp: add a return code to " Tycho Andersen 2018-02-13 21:09 ` Kees Cook [not found] ` <CAGXu5jLAAKY19a9iC1PmXRyuwdn1Zxr2Cb318zdzkqgYt8vtdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-14 15:29 ` Tycho Andersen 2018-02-14 15:29 ` Tycho Andersen 2018-02-14 17:19 ` Andy Lutomirski 2018-02-14 17:23 ` Tycho Andersen 2018-02-15 14:48 ` Christian Brauner [not found] ` <CALCETrXeZZfVzXh7SwKhyB=+ySDk5fhrrdrXrcABsQ=JpQT7Tg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-14 17:23 ` Tycho Andersen 2018-02-15 14:48 ` Christian Brauner 2018-02-27 0:49 ` Kees Cook 2018-02-27 0:49 ` Kees Cook [not found] ` <CAGXu5jKBmej+fXhEc+Jy7Guy+vXEZkHnc=4LNm1NNEsc1=DFVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-27 3:27 ` Andy Lutomirski 2018-02-27 3:27 ` Andy Lutomirski 2018-02-14 17:19 ` Andy Lutomirski [not found] ` <20180204104946.25559-2-tycho-E0fblnxP3wo@public.gmane.org> 2018-02-04 17:36 ` Andy Lutomirski [this message] 2018-02-04 17:36 ` Andy Lutomirski [not found] ` <CALCETrWgu5n+SMqrsZQ7MVYPtzs8otuc7hpA5uPH+JNtFrMBkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-04 20:01 ` Tycho Andersen 2018-02-04 20:01 ` Tycho Andersen 2018-02-04 20:33 ` Andy Lutomirski [not found] ` <CALCETrV81yr_zhuBbCTE8NgYx42oq=qvP=nLMsST0iS2wtOZng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-05 8:47 ` Tycho Andersen 2018-02-05 8:47 ` Tycho Andersen 2018-02-04 20:33 ` Andy Lutomirski 2018-02-13 21:09 ` Kees Cook 2018-02-04 10:49 ` [RFC 2/3] seccomp: hoist out filter resolving logic Tycho Andersen [not found] ` <20180204104946.25559-3-tycho-E0fblnxP3wo@public.gmane.org> 2018-02-13 21:29 ` Kees Cook 2018-02-13 21:29 ` Kees Cook 2018-02-14 15:33 ` Tycho Andersen 2018-02-14 15:33 ` Tycho Andersen [not found] ` <20180204104946.25559-1-tycho-E0fblnxP3wo@public.gmane.org> 2018-02-04 10:49 ` [RFC 1/3] seccomp: add a return code to trap to userspace Tycho Andersen 2018-02-04 10:49 ` [RFC 2/3] seccomp: hoist out filter resolving logic Tycho Andersen 2018-02-04 10:49 ` [RFC 3/3] seccomp: add a way to get a listener fd from ptrace Tycho Andersen 2018-03-15 16:09 ` [RFC 0/3] seccomp trap to userspace Christian Brauner 2018-02-04 10:49 ` [RFC 3/3] seccomp: add a way to get a listener fd from ptrace Tycho Andersen [not found] ` <20180204104946.25559-4-tycho-E0fblnxP3wo@public.gmane.org> 2018-02-13 21:32 ` Kees Cook 2018-02-13 21:32 ` Kees Cook [not found] ` <CAGXu5jLS2dzCjZOKa-W4kUdOPoJkRAq5Rsw1t5jX99v34yaoQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-14 15:33 ` Tycho Andersen 2018-02-14 15:33 ` Tycho Andersen 2018-03-15 16:09 ` [RFC 0/3] seccomp trap to userspace Christian Brauner [not found] ` <20180315160924.GA12744-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2018-03-15 16:56 ` Andy Lutomirski 2018-03-15 16:56 ` Andy Lutomirski 2018-03-15 17:05 ` Serge E. Hallyn 2018-03-15 17:11 ` Andy Lutomirski 2018-03-15 17:35 ` Tycho Andersen 2018-03-16 0:46 ` Andy Lutomirski 2018-03-16 0:46 ` Andy Lutomirski [not found] ` <CALCETrWH7HbY2gS6O_cYKfp9QqqWBWVcHb++GaP3uUiSO9oo6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-16 14:47 ` Christian Brauner 2018-03-16 14:47 ` Christian Brauner 2018-03-16 16:01 ` Andy Lutomirski [not found] ` <D73E5C37-DC92-4D58-A163-0B20143AAEEB-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> 2018-03-16 16:40 ` Christian Brauner 2018-03-16 16:40 ` Christian Brauner [not found] ` <20180316144751.GA3304-cl+VPiYnx/1AfugRpC6u6w@public.gmane.org> 2018-03-16 16:01 ` Andy Lutomirski [not found] ` <CALCETrXPcCNbpFJhXktkVS9gOPpmnU_bbY6Z8RrsBarq0dP4Lg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-15 17:25 ` Christian Brauner 2018-03-15 17:25 ` Christian Brauner [not found] ` <20180315172558.GA28108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2018-03-15 17:30 ` Andy Lutomirski 2018-03-15 17:30 ` Andy Lutomirski 2018-03-15 17:35 ` Tycho Andersen [not found] ` <20180315170509.GA32766-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> 2018-03-15 17:11 ` Andy Lutomirski [not found] ` <CALCETrVnvbZLx5v=DMu2N1JtR+ys507X5CYBi-qQnus3VMQdwg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-15 17:05 ` Serge E. Hallyn
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=CALCETrWgu5n+SMqrsZQ7MVYPtzs8otuc7hpA5uPH+JNtFrMBkQ@mail.gmail.com \ --to=luto-klttt9wpgjjwatoyat5jvq@public.gmane.org \ --cc=christian.brauner-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \ --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \ --cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=suda.akihiro-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \ --cc=tycho-E0fblnxP3wo@public.gmane.org \ --cc=tyhicks-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.