From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [RFC 3/3] seccomp: add a way to get a listener fd from ptrace Date: Tue, 13 Feb 2018 13:32:26 -0800 Message-ID: References: <20180204104946.25559-1-tycho@tycho.ws> <20180204104946.25559-4-tycho@tycho.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180204104946.25559-4-tycho-E0fblnxP3wo@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tycho Andersen Cc: Linux Containers , Akihiro Suda , Oleg Nesterov , LKML , "Eric W . Biederman" , Tyler Hicks , Christian Brauner , Andy Lutomirski List-Id: containers.vger.kernel.org On Sun, Feb 4, 2018 at 2:49 AM, 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 aren't cooperating with you > 2. You can control tasks whose filters block sendmsg() and socket(); if the > task installs a filter which blocks these calls, there's no way with > SECCOMP_FILTER_FLAG_GET_LISTENER to get the fd out to the privileged task. I got worried for a second that this would get us into a many-to-many state, but I see init_listener enforces a single listener per filter. Whew. Seems legit. :) -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965889AbeBMVc3 (ORCPT ); Tue, 13 Feb 2018 16:32:29 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:46759 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965749AbeBMVc1 (ORCPT ); Tue, 13 Feb 2018 16:32:27 -0500 X-Google-Smtp-Source: AH8x226Vn0/Gr4Dp5M7B3j/3+f3153mFYRhx6DS+6gIUhlsRWXonqlrviWNh+MdBG5ITM5p2xmLLZA5htYaRiFyzoxw= MIME-Version: 1.0 In-Reply-To: <20180204104946.25559-4-tycho@tycho.ws> References: <20180204104946.25559-1-tycho@tycho.ws> <20180204104946.25559-4-tycho@tycho.ws> From: Kees Cook Date: Tue, 13 Feb 2018 13:32:26 -0800 X-Google-Sender-Auth: uI6ZsRTzXZHuWrZaobzRo0vcjto Message-ID: Subject: Re: [RFC 3/3] seccomp: add a way to get a listener fd from ptrace To: Tycho Andersen Cc: LKML , Linux Containers , Andy Lutomirski , Oleg Nesterov , "Eric W . Biederman" , "Serge E . Hallyn" , Christian Brauner , Tyler Hicks , Akihiro Suda 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 Sun, Feb 4, 2018 at 2:49 AM, 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 aren't cooperating with you > 2. You can control tasks whose filters block sendmsg() and socket(); if the > task installs a filter which blocks these calls, there's no way with > SECCOMP_FILTER_FLAG_GET_LISTENER to get the fd out to the privileged task. I got worried for a second that this would get us into a many-to-many state, but I see init_listener enforces a single listener per filter. Whew. Seems legit. :) -Kees -- Kees Cook Pixel Security