On Thu, Oct 11, 2018 at 9:24 AM Paul Moore wrote:
> On October 10, 2018 11:34:11 AM Jann Horn wrote:
> > On Wed, Oct 10, 2018 at 5:32 PM Paul Moore wrote:
> >> On Tue, Oct 9, 2018 at 9:36 AM Jann Horn wrote:
> >>> +cc selinux people explicitly, sin
On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
> On Wed 10-10-18 17:27:36, Jann Horn wrote:
> > Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
> > application causes that application to randomly crash. The existing check
> > for handling MAP_FIX
On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko wrote:
> On Wed 10-10-18 17:27:36, Jann Horn wrote:
> > Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
> > application causes that application to randomly crash. The existing check
> > for handling MAP_FIX
On Wed, Oct 10, 2018 at 5:32 PM Paul Moore wrote:
> On Tue, Oct 9, 2018 at 9:36 AM Jann Horn wrote:
> > +cc selinux people explicitly, since they probably have opinions on this
>
> I just spent about twenty minutes working my way through this thread,
> and digging through the
On Wed, Oct 10, 2018 at 5:32 PM Paul Moore wrote:
> On Tue, Oct 9, 2018 at 9:36 AM Jann Horn wrote:
> > +cc selinux people explicitly, since they probably have opinions on this
>
> I just spent about twenty minutes working my way through this thread,
> and digging through the
On Tue, Oct 9, 2018 at 6:57 PM Laurent Vivier wrote:
> Le 09/10/2018 à 18:53, Jann Horn a écrit :
> > On Tue, Oct 9, 2018 at 6:45 PM Laurent Vivier wrote:
> >> Le 09/10/2018 à 18:15, Kirill Tkhai a écrit :
> >>> On 09.10.2018 13:37, Laurent Vivier wrote:
&g
On Tue, Oct 9, 2018 at 6:57 PM Laurent Vivier wrote:
> Le 09/10/2018 à 18:53, Jann Horn a écrit :
> > On Tue, Oct 9, 2018 at 6:45 PM Laurent Vivier wrote:
> >> Le 09/10/2018 à 18:15, Kirill Tkhai a écrit :
> >>> On 09.10.2018 13:37, Laurent Vivier wrote:
&g
On Tue, Oct 9, 2018 at 6:45 PM Laurent Vivier wrote:
> Le 09/10/2018 à 18:15, Kirill Tkhai a écrit :
> > On 09.10.2018 13:37, Laurent Vivier wrote:
> >> This patch allows to have a different binfmt_misc configuration
> >> for each new user namespace. By default, the binfmt_misc configuration
> >>
On Tue, Oct 9, 2018 at 6:45 PM Laurent Vivier wrote:
> Le 09/10/2018 à 18:15, Kirill Tkhai a écrit :
> > On 09.10.2018 13:37, Laurent Vivier wrote:
> >> This patch allows to have a different binfmt_misc configuration
> >> for each new user namespace. By default, the binfmt_misc configuration
> >>
On Tue, Oct 9, 2018 at 5:36 PM Aleksa Sarai wrote:
> On 2018-10-09, 'Jann Horn' via dev wrote:
> > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote:
> > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".."
> > > resolution (in
On Tue, Oct 9, 2018 at 5:36 PM Aleksa Sarai wrote:
> On 2018-10-09, 'Jann Horn' via dev wrote:
> > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote:
> > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".."
> > > resolution (in
mean "before"? Otherwise I don't understand what
you're saying here.
> and thus will
> not be able to escape from the previously-inside-root path. Walking down
> is still safe since the entire subtree was moved (either by rename(2) or
> MS_MOVE) and because (as discussed abov
mean "before"? Otherwise I don't understand what
you're saying here.
> and thus will
> not be able to escape from the previously-inside-root path. Walking down
> is still safe since the entire subtree was moved (either by rename(2) or
> MS_MOVE) and because (as discussed abov
On Tue, Oct 9, 2018 at 3:06 PM Laurent Vivier wrote:
>
> Le 09/10/2018 à 14:43, Jann Horn a écrit :
> > On Tue, Oct 9, 2018 at 12:38 PM Laurent Vivier wrote:
> >> This patch allows to have a different binfmt_misc configuration
> >> for each new user namespac
On Tue, Oct 9, 2018 at 3:06 PM Laurent Vivier wrote:
>
> Le 09/10/2018 à 14:43, Jann Horn a écrit :
> > On Tue, Oct 9, 2018 at 12:38 PM Laurent Vivier wrote:
> >> This patch allows to have a different binfmt_misc configuration
> >> for each new user namespac
On Tue, Oct 9, 2018 at 12:38 PM Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace
On Tue, Oct 9, 2018 at 12:38 PM Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace
On Mon, Oct 8, 2018 at 8:18 PM Christian Brauner wrote:
> On Mon, Oct 08, 2018 at 06:42:00PM +0200, Jann Horn wrote:
> > On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner
> > wrote:
> > > On Mon, Oct 08, 2018 at 05:33:22PM +0200, Jann Horn wrote:
> > > > On M
On Mon, Oct 8, 2018 at 8:18 PM Christian Brauner wrote:
> On Mon, Oct 08, 2018 at 06:42:00PM +0200, Jann Horn wrote:
> > On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner
> > wrote:
> > > On Mon, Oct 08, 2018 at 05:33:22PM +0200, Jann Horn wrote:
> > > > On M
On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner wrote:
> On Mon, Oct 08, 2018 at 05:33:22PM +0200, Jann Horn wrote:
> > On Mon, Oct 8, 2018 at 5:16 PM Christian Brauner
> > wrote:
> > >
> > > On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen
On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner wrote:
> On Mon, Oct 08, 2018 at 05:33:22PM +0200, Jann Horn wrote:
> > On Mon, Oct 8, 2018 at 5:16 PM Christian Brauner
> > wrote:
> > >
> > > On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen
On Mon, Oct 8, 2018 at 5:16 PM Christian Brauner wrote:
>
> On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen wrote:
> > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > version which can acquire filters is useful. There are at least two reasons
> > this is
On Mon, Oct 8, 2018 at 5:16 PM Christian Brauner wrote:
>
> On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen wrote:
> > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > version which can acquire filters is useful. There are at least two reasons
> > this is
On Sat, Oct 6, 2018 at 9:36 PM Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace a
On Sat, Oct 6, 2018 at 9:36 PM Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the previous level, but if the binfmt_misc filesystem is
> mounted in the new namespace a
On Sat, Oct 6, 2018 at 8:04 AM Andrei Vagin wrote:
> On Thu, Oct 04, 2018 at 12:50:22AM +0200, Laurent Vivier wrote:
> > This patch allows to have a different binfmt_misc configuration
> > for each new user namespace. By default, the binfmt_misc configuration
> > is the one of the host, but if
On Sat, Oct 6, 2018 at 8:04 AM Andrei Vagin wrote:
> On Thu, Oct 04, 2018 at 12:50:22AM +0200, Laurent Vivier wrote:
> > This patch allows to have a different binfmt_misc configuration
> > for each new user namespace. By default, the binfmt_misc configuration
> > is the one of the host, but if
On Sat, Oct 6, 2018 at 4:10 AM Aleksa Sarai wrote:
> On 2018-10-05, Jann Horn wrote:
> > > What if we took rename_lock (call it nd->r_seq) at the start of the
> > > resolution, and then only tried the __d_path-style check
> > >
> >
On Sat, Oct 6, 2018 at 4:10 AM Aleksa Sarai wrote:
> On 2018-10-05, Jann Horn wrote:
> > > What if we took rename_lock (call it nd->r_seq) at the start of the
> > > resolution, and then only tried the __d_path-style check
> > >
> >
the ALU op, since that has
no effect.
Fixes: 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification")
Acked-by: Daniel Borkmann
Signed-off-by: Jann Horn
---
kernel/bpf/verifier.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/
the ALU op, since that has
no effect.
Fixes: 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification")
Acked-by: Daniel Borkmann
Signed-off-by: Jann Horn
---
kernel/bpf/verifier.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/
On Fri, Oct 5, 2018 at 5:07 PM Aleksa Sarai wrote:
> On 2018-10-04, Jann Horn wrote:
> > On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > You attempt to open "C/../../etc/passwd" under the root "/A/
On Fri, Oct 5, 2018 at 5:07 PM Aleksa Sarai wrote:
> On 2018-10-04, Jann Horn wrote:
> > On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > You attempt to open "C/../../etc/passwd" under the root "/A/
On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> >
On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> >
On Wed, Oct 3, 2018 at 8:07 AM Eric W. Biederman wrote:
> Laurent Vivier writes:
> > This patch allows to have a different binftm_misc configuration
> > in each container we mount binfmt_misc filesystem with mount namespace
> > enabled.
> >
> > A container started without the CLONE_NEWNS will
On Wed, Oct 3, 2018 at 8:07 AM Eric W. Biederman wrote:
> Laurent Vivier writes:
> > This patch allows to have a different binftm_misc configuration
> > in each container we mount binfmt_misc filesystem with mount namespace
> > enabled.
> >
> > A container started without the CLONE_NEWNS will
On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
wrote:
> On 01.10.2018 19:11, Thomas Gleixner wrote:
> > Peter and I discussed that and we came up with the idea that the file
> > descriptor is not even required, i.e. you could make it backward
> > compatible.
> >
> > perf_event_open() knows which
On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
wrote:
> On 01.10.2018 19:11, Thomas Gleixner wrote:
> > Peter and I discussed that and we came up with the idea that the file
> > descriptor is not even required, i.e. you could make it backward
> > compatible.
> >
> > perf_event_open() knows which
Hi!
I noticed that X86-64 is using the generic string functions from
lib/string.c for things like strlen(), strchr(), memcmp() and so on.
Is that an intentional omission, because they're not considered worth
optimizing, or is this an oversight? The kernel doesn't use string
functions much, but if
Hi!
I noticed that X86-64 is using the generic string functions from
lib/string.c for things like strlen(), strchr(), memcmp() and so on.
Is that an intentional omission, because they're not considered worth
optimizing, or is this an oversight? The kernel doesn't use string
functions much, but if
+Andy for opinions on things in write handlers
+Mimi Zohar as EVM maintainer
On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
> > wrote:
> > > This patch adds
+Andy for opinions on things in write handlers
+Mimi Zohar as EVM maintainer
On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
> > wrote:
> > > This patch adds
On Mon, Oct 1, 2018 at 6:12 PM Thomas Gleixner wrote:
> From a design POV, Jann's idea to have a per PMU special file which you
> need to open for getting access is way better than the extra knobs. It
> allows to use all existing security mechanisms to be used.
(That was Mark's idea, not mine, I
On Mon, Oct 1, 2018 at 6:12 PM Thomas Gleixner wrote:
> From a design POV, Jann's idea to have a per PMU special file which you
> need to open for getting access is way better than the extra knobs. It
> allows to use all existing security mechanisms to be used.
(That was Mark's idea, not mine, I
On Sat, Sep 29, 2018 at 4:28 PM Aleksa Sarai wrote:
> Add the following flags for path resolution. The primary justification
> for these flags is to allow for programs to be far more strict about how
> they want path resolution to handle symlinks, mountpoint crossings, and
> paths that escape the
On Sat, Sep 29, 2018 at 4:28 PM Aleksa Sarai wrote:
> Add the following flags for path resolution. The primary justification
> for these flags is to allow for programs to be far more strict about how
> they want path resolution to handle symlinks, mountpoint crossings, and
> paths that escape the
On Mon, Oct 1, 2018 at 12:42 PM Christian Brauner wrote:
> On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> > On 2018-09-29, Jann Horn wrote:
> > > The problem is what happens if a folder you are walking through is
> > > concurrently moved out of the chr
On Mon, Oct 1, 2018 at 12:42 PM Christian Brauner wrote:
> On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> > On 2018-09-29, Jann Horn wrote:
> > > The problem is what happens if a folder you are walking through is
> > > concurrently moved out of the chr
On Mon, Oct 1, 2018 at 7:44 AM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/
On Mon, Oct 1, 2018 at 7:44 AM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/
On Mon, Oct 1, 2018 at 1:47 AM Laurent Vivier wrote:
> @@ -716,7 +711,8 @@ static ssize_t bm_register_write(struct file *file, const
> char __user *buffer,
> if (!inode)
> goto out2;
>
> - err = simple_pin_fs(_fs_type, _mnt, _count);
> + err =
On Mon, Oct 1, 2018 at 1:47 AM Laurent Vivier wrote:
> @@ -716,7 +711,8 @@ static ssize_t bm_register_write(struct file *file, const
> char __user *buffer,
> if (!inode)
> goto out2;
>
> - err = simple_pin_fs(_fs_type, _mnt, _count);
> + err =
On Sun, Sep 30, 2018 at 10:39 PM Mickaël Salaün wrote:
> As a side note, I'm still working on Landlock which can achieve the same
> goal but in a more flexible and dynamic way: https://landlock.io
Isn't Landlock mostly intended for userspace that wants to impose a
custom Mandatory Access Control
On Sun, Sep 30, 2018 at 10:39 PM Mickaël Salaün wrote:
> As a side note, I'm still working on Landlock which can achieve the same
> goal but in a more flexible and dynamic way: https://landlock.io
Isn't Landlock mostly intended for userspace that wants to impose a
custom Mandatory Access Control
+cc linux-api; please keep them in CC for future versions of the patch
On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
> The primary motivation for the need for this flag is container runtimes
> which have to interact with malicious root filesystems in the host
> namespaces. One of the first
+cc linux-api; please keep them in CC for future versions of the patch
On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
> The primary motivation for the need for this flag is container runtimes
> which have to interact with malicious root filesystems in the host
> namespaces. One of the first
On Sat, Sep 29, 2018 at 12:47 AM Michael Kerrisk (man-pages)
wrote:
> On Sat, 29 Sep 2018 at 00:35, Kees Cook wrote:
> > On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages)
> > wrote:
> > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote:
> > >> On Fri, Sep 28, 2018 at 11:57:40PM
On Sat, Sep 29, 2018 at 12:47 AM Michael Kerrisk (man-pages)
wrote:
> On Sat, 29 Sep 2018 at 00:35, Kees Cook wrote:
> > On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages)
> > wrote:
> > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote:
> > >> On Fri, Sep 28, 2018 at 11:57:40PM
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote:
>
> On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
> wrote:
> > On 28/09/2018 11:26, Thomas Gleixner wrote:
> > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> > >> For situations where sysadmins might want to al
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote:
>
> On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
> wrote:
> > On 28/09/2018 11:26, Thomas Gleixner wrote:
> > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> > >> For situations where sysadmins might want to al
On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote:
> On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote:
> > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote:
> > >
> > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote:
> > > >
On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote:
> On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote:
> > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote:
> > >
> > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote:
> > > >
On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > This new file descriptor argument doesn't exist today so it would
> > > need to create a new system call with more arguments
> >
> > Is that true? The first argument is a pointer to a struct that
> > contains its own size, so it can be
On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > This new file descriptor argument doesn't exist today so it would
> > > need to create a new system call with more arguments
> >
> > Is that true? The first argument is a pointer to a struct that
> > contains its own size, so it can be
On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote:
>
> On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote:
> > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote:
> > > As Jann pointed out, there is a race between SECCOMP_FILTER_FLAG_TSYNC and
> > > th
On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote:
>
> On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote:
> > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote:
> > > As Jann pointed out, there is a race between SECCOMP_FILTER_FLAG_TSYNC and
> > > th
On Fri, Sep 28, 2018 at 10:49 PM Andi Kleen wrote:
>
> On Fri, Sep 28, 2018 at 06:40:17PM +0100, Mark Rutland wrote:
> > On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > > > There's also been prior discussion on these feature in other contexts
> > > > (e.g. android expoits
On Fri, Sep 28, 2018 at 10:49 PM Andi Kleen wrote:
>
> On Fri, Sep 28, 2018 at 06:40:17PM +0100, Mark Rutland wrote:
> > On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > > > There's also been prior discussion on these feature in other contexts
> > > > (e.g. android expoits
that true? The ptrace code uses get_nth_filter(), which holds
the siglock while grabbing the seccomp filter and bumping its
refcount. And TSYNC happens from seccomp_set_mode_filter(), which
takes the siglock. So this looks okay to me?
> Signed-off-by: Tycho Andersen
> Reported-by: Jann Horn
that true? The ptrace code uses get_nth_filter(), which holds
the siglock while grabbing the seccomp filter and bumping its
refcount. And TSYNC happens from seccomp_set_mode_filter(), which
takes the siglock. So this looks okay to me?
> Signed-off-by: Tycho Andersen
> Reported-by: Jann Horn
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On Fri, Sep 28, 2018 at 4:20 AM Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not just
On Fri, Sep 28, 2018 at 4:20 AM Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not just
On Fri, Sep 28, 2018 at 1:43 AM James Morris wrote:
> On Thu, 27 Sep 2018, Schaufler, Casey wrote:
> > > > On 9/27/2018 2:45 PM, James Morris wrote:
> > > > > On Wed, 26 Sep 2018, Casey Schaufler wrote:
> > > > >
> > > > >> + /*
> > > > >> + * Namespace checks. Considered safe if:
> >
On Fri, Sep 28, 2018 at 1:43 AM James Morris wrote:
> On Thu, 27 Sep 2018, Schaufler, Casey wrote:
> > > > On 9/27/2018 2:45 PM, James Morris wrote:
> > > > > On Wed, 26 Sep 2018, Casey Schaufler wrote:
> > > > >
> > > > >> + /*
> > > > >> + * Namespace checks. Considered safe if:
> >
On Fri, Sep 28, 2018 at 1:04 AM Tycho Andersen wrote:
> On Thu, Sep 27, 2018 at 11:51:40PM +0200, Jann Horn wrote:
> > > +It is worth noting that ``struct seccomp_data`` contains the values of
> > > register
> > > +arguments to the syscall, but does
On Fri, Sep 28, 2018 at 1:04 AM Tycho Andersen wrote:
> On Thu, Sep 27, 2018 at 11:51:40PM +0200, Jann Horn wrote:
> > > +It is worth noting that ``struct seccomp_data`` contains the values of
> > > register
> > > +arguments to the syscall, but does
On Fri, Sep 28, 2018 at 12:29 AM Andrew Morton
wrote:
>
> On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn wrote:
>
> > Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> > in order to prevent a local attacker from exploiting racy stack unwinding
> >
On Fri, Sep 28, 2018 at 12:29 AM Andrew Morton
wrote:
>
> On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn wrote:
>
> > Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> > in order to prevent a local attacker from exploiting racy stack unwinding
> >
On Fri, Sep 28, 2018 at 12:14 AM Tycho Andersen wrote:
> On Thu, Sep 27, 2018 at 09:28:07PM +0200, Jann Horn wrote:
> > On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> > > This patch adds a way to insert FDs into the tracee's process (also
> > > close/o
On Fri, Sep 28, 2018 at 12:14 AM Tycho Andersen wrote:
> On Thu, Sep 27, 2018 at 09:28:07PM +0200, Jann Horn wrote:
> > On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> > > This patch adds a way to insert FDs into the tracee's process (also
> > > close/o
+Christoph Hellwig, Al Viro, fsdevel: For two questions about the poll
interface (search for "seccomp_notify_poll" and
"seccomp_notify_release" in the patch)
@Tycho: FYI, I've gone through all of v7 now, apart from the
test/sample code. So don't wait for more comments from me before
sending out
+Christoph Hellwig, Al Viro, fsdevel: For two questions about the poll
interface (search for "seccomp_notify_poll" and
"seccomp_notify_release" in the patch)
@Tycho: FYI, I've gone through all of v7 now, apart from the
test/sample code. So don't wait for more comments from me before
sending out
On Thu, Sep 27, 2018 at 9:17 PM Casey Schaufler
wrote:
>
> From: Casey Schaufler
>
> The PTRACE_MODE_SCHED check erroniously returns 0 in
> all cases. It should be returning -EPERM. This fixes
> the logic to correct that error.
>
> Signed-off-by: Casey Schaufler
On Thu, Sep 27, 2018 at 9:17 PM Casey Schaufler
wrote:
>
> From: Casey Schaufler
>
> The PTRACE_MODE_SCHED check erroniously returns 0 in
> all cases. It should be returning -EPERM. This fixes
> the logic to correct that error.
>
> Signed-off-by: Casey Schaufler
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> This patch adds a way to insert FDs into the tracee's process (also
> close/overwrite fds for the tracee). This functionality is necessary to
> mock things like socketpair() or dup2() or similar, but since it depends on
> external (vfs)
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> This patch adds a way to insert FDs into the tracee's process (also
> close/overwrite fds for the tracee). This functionality is necessary to
> mock things like socketpair() or dup2() or similar, but since it depends on
> external (vfs)
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
t; CC: Eric W. Biederman
> CC: "Serge E. Hallyn"
> CC: Christian Brauner
> CC: Tyler Hicks
> CC: Akihiro Suda
Reviewed-by: Jann Horn
> ---
> kernel/seccomp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/seccomp.c
t; CC: Eric W. Biederman
> CC: "Serge E. Hallyn"
> CC: Christian Brauner
> CC: Tyler Hicks
> CC: Akihiro Suda
Reviewed-by: Jann Horn
> ---
> kernel/seccomp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/seccomp.c
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> an arbitrary struct files_struct, not just current's. We'll use this in the
> next patch to implement the seccomp ioctl that allows inserting fds into a
> stopped
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> an arbitrary struct files_struct, not just current's. We'll use this in the
> next patch to implement the seccomp ioctl that allows inserting fds into a
> stopped
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> This patch adds a way to insert FDs into the tracee's process (also
> close/overwrite fds for the tracee). This functionality is necessary to
> mock things like socketpair() or dup2() or similar, but since it depends on
> external (vfs)
On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote:
> This patch adds a way to insert FDs into the tracee's process (also
> close/overwrite fds for the tracee). This functionality is necessary to
> mock things like socketpair() or dup2() or similar, but since it depends on
> external (vfs)
w listener at the right filter (Jann)
>
> Signed-off-by: Tycho Andersen
> CC: Kees Cook
> CC: Andy Lutomirski
> CC: Oleg Nesterov
> CC: Eric W. Biederman
> CC: "Serge E. Hallyn"
> CC: Christian Brauner
> CC: Tyler Hicks
> CC: Akihiro Suda
If you addr
w listener at the right filter (Jann)
>
> Signed-off-by: Tycho Andersen
> CC: Kees Cook
> CC: Andy Lutomirski
> CC: Oleg Nesterov
> CC: Eric W. Biederman
> CC: "Serge E. Hallyn"
> CC: Christian Brauner
> CC: Tyler Hicks
> CC: Akihiro Suda
If you addr
On Wed, Sep 19, 2018 at 6:13 PM Cyrill Gorcunov wrote:
>
> On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote:
> ...
> > >
> > > Heh, actually not :) It is due to commit
> > >
> > > commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> > >
701 - 800 of 1477 matches
Mail list logo
