From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752140AbaG0MKe (ORCPT ); Sun, 27 Jul 2014 08:10:34 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:55443 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751821AbaG0MKc (ORCPT ); Sun, 27 Jul 2014 08:10:32 -0400 MIME-Version: 1.0 In-Reply-To: References: <1406296033-32693-1-git-send-email-drysdale@google.com> <1406296033-32693-12-git-send-email-drysdale@google.com> From: David Drysdale Date: Sun, 27 Jul 2014 13:10:10 +0100 Message-ID: Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data To: Andy Lutomirski Cc: Julien Tinnes , Kees Cook , "Eric W. Biederman" , Al Viro , Paolo Bonzini , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 25, 2014 at 7:32 PM, Andy Lutomirski wrote: > On Fri, Jul 25, 2014 at 11:22 AM, Julien Tinnes wrote: >> On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook wrote: >>> >>> On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski >>> wrote: >>> > [cc: Eric Biederman] >>> > >>> > On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook >>> > wrote: >>> >>> >> Julien had been wanting something like this too (though he'd suggested >>> >> it via prctl): limit the signal functions to "self" only. I wonder if >>> >> adding a prctl like done for O_BENEATH could work for signal sending? >>> >> >>> > >>> > >>> > Can we do one better and add a flag to prevent any non-self pid >>> > lookups? This might actually be easy on top of the pid namespace work >>> > (e.g. we could change the way that find_task_by_vpid works). >>> >>> Ooh, that would be extremely interesting, yes. Kind of an extreme form >>> of pid namespace without actually being a namespace. >>> >>> > It's far from just being signals. There's access_process_vm, ptrace, >>> > all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this >>> > is ridiculous), and probably some others that I've forgotten about or >>> > never noticed in the first place. >>> >>> Yeah, that would be very interesting. >> >> >> Yes, this would be incredibly useful. >> >> 1. For Chromium [1], I dislike relying on seccomp purely for >> "access-control" (to other processes or files). Because it's really hard to >> think about everything (things like CPUCLOCK_PID bite, see >> https://crbug.com/374479). > > Not public :( > >> Se we have a first layer of sandboxing (using PID + NET namespaces and >> chroot) for "access-control" and a second layer for kernel attack surface >> reduction and a few other things using seccomp-bpf. >> >> The first layer isn't currently very good; it's heavyweight and complex (you >> need an init(1) per namespace and that init cannot be multi-purposed as a >> useful process because pid = 1 can never receive signals). One PID namespace >> per process isn't something that scales well. (Also before USER_NS it >> required a setuid root program). >> >> 2. Even with a safe pure seccomp-bpf sandbox that prevents sending signals >> to other process / ptrace() et al and that restrict clock_gettime(2) >> properly, things become quickly very tedious because as far as the kernel is >> concerned, the process under this BPF program can still pass >> ptrace_may_access() to other processes. This means for instance that no >> matter what you do, a model where open() is allowed can't work if /proc is >> available. We need a mode that says "ptrace_may_access()" will never pass. >> >> So yes, I really would like: >> - a prctl that says: "I'm dropping privileges and I now can't interact with >> other thread groups (via signals, ptrace, etc..)". >> - Something to drop access to the file system. It could be an unprivileged >> way to chroot() to an empty directory (unprivileged namespaces work for >> that, - except if you're already in a chroot -). This is a little tricky >> without allowing chroot escapes, so I suspect we would want to express it in >> terms of mount namespace, or something else, rather than chroot. > > Capsicum will give you this. Yep, that's the idea. As long as there aren't any open DFDs for "/proc" on entry to capability mode, there shouldn't be a way to access it later -- but it is still possible to openat(2) new files (relative to a pre-opened DFD). > See the other thread for a more concrete proposal. prctl is getting > out of hand. > > --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Drysdale Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data Date: Sun, 27 Jul 2014 13:10:10 +0100 Message-ID: References: <1406296033-32693-1-git-send-email-drysdale@google.com> <1406296033-32693-12-git-send-email-drysdale@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: Julien Tinnes , Kees Cook , "Eric W. Biederman" , Al Viro , Paolo Bonzini , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-api@vger.kernel.org On Fri, Jul 25, 2014 at 7:32 PM, Andy Lutomirski wrote: > On Fri, Jul 25, 2014 at 11:22 AM, Julien Tinnes wrote: >> On Fri, Jul 25, 2014 at 10:38 AM, Kees Cook wrote: >>> >>> On Fri, Jul 25, 2014 at 10:18 AM, Andy Lutomirski >>> wrote: >>> > [cc: Eric Biederman] >>> > >>> > On Fri, Jul 25, 2014 at 10:10 AM, Kees Cook >>> > wrote: >>> >>> >> Julien had been wanting something like this too (though he'd suggested >>> >> it via prctl): limit the signal functions to "self" only. I wonder if >>> >> adding a prctl like done for O_BENEATH could work for signal sending? >>> >> >>> > >>> > >>> > Can we do one better and add a flag to prevent any non-self pid >>> > lookups? This might actually be easy on top of the pid namespace work >>> > (e.g. we could change the way that find_task_by_vpid works). >>> >>> Ooh, that would be extremely interesting, yes. Kind of an extreme form >>> of pid namespace without actually being a namespace. >>> >>> > It's far from just being signals. There's access_process_vm, ptrace, >>> > all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this >>> > is ridiculous), and probably some others that I've forgotten about or >>> > never noticed in the first place. >>> >>> Yeah, that would be very interesting. >> >> >> Yes, this would be incredibly useful. >> >> 1. For Chromium [1], I dislike relying on seccomp purely for >> "access-control" (to other processes or files). Because it's really hard to >> think about everything (things like CPUCLOCK_PID bite, see >> https://crbug.com/374479). > > Not public :( > >> Se we have a first layer of sandboxing (using PID + NET namespaces and >> chroot) for "access-control" and a second layer for kernel attack surface >> reduction and a few other things using seccomp-bpf. >> >> The first layer isn't currently very good; it's heavyweight and complex (you >> need an init(1) per namespace and that init cannot be multi-purposed as a >> useful process because pid = 1 can never receive signals). One PID namespace >> per process isn't something that scales well. (Also before USER_NS it >> required a setuid root program). >> >> 2. Even with a safe pure seccomp-bpf sandbox that prevents sending signals >> to other process / ptrace() et al and that restrict clock_gettime(2) >> properly, things become quickly very tedious because as far as the kernel is >> concerned, the process under this BPF program can still pass >> ptrace_may_access() to other processes. This means for instance that no >> matter what you do, a model where open() is allowed can't work if /proc is >> available. We need a mode that says "ptrace_may_access()" will never pass. >> >> So yes, I really would like: >> - a prctl that says: "I'm dropping privileges and I now can't interact with >> other thread groups (via signals, ptrace, etc..)". >> - Something to drop access to the file system. It could be an unprivileged >> way to chroot() to an empty directory (unprivileged namespaces work for >> that, - except if you're already in a chroot -). This is a little tricky >> without allowing chroot escapes, so I suspect we would want to express it in >> terms of mount namespace, or something else, rather than chroot. > > Capsicum will give you this. Yep, that's the idea. As long as there aren't any open DFDs for "/proc" on entry to capability mode, there shouldn't be a way to access it later -- but it is still possible to openat(2) new files (relative to a pre-opened DFD). > See the other thread for a more concrete proposal. prctl is getting > out of hand. > > --Andy