From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f196.google.com ([209.85.214.196]:44341 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbeJIBNj (ORCPT ); Mon, 8 Oct 2018 21:13:39 -0400 Received: by mail-pl1-f196.google.com with SMTP id p25-v6so10411449pli.11 for ; Mon, 08 Oct 2018 11:00:46 -0700 (PDT) Date: Mon, 8 Oct 2018 12:00:43 -0600 From: Tycho Andersen To: Christian Brauner Cc: Kees Cook , Jann Horn , linux-api@vger.kernel.org, containers@lists.linux-foundation.org, Akihiro Suda , Oleg Nesterov , linux-kernel@vger.kernel.org, "Eric W . Biederman" , linux-fsdevel@vger.kernel.org, Christian Brauner , Andy Lutomirski Subject: Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace Message-ID: <20181008180043.GE28238@cisco.lan> References: <20180927151119.9989-1-tycho@tycho.ws> <20180927151119.9989-4-tycho@tycho.ws> <20181008151629.hkgzzsluevwtuclw@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181008151629.hkgzzsluevwtuclw@brauner.io> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Oct 08, 2018 at 05:16:30PM +0200, 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 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. > > So for the slow of mind aka me: > I'm not sure I completely understand this problem. Can you outline how > sendmsg() and socket() are involved in this? > > I'm also not sure that this holds (but I might misunderstand the > problem) afaict, you could do try to get the fd out via CLONE_FILES and > other means so something like: > > // let's pretend the libc wrapper for clone actually has sane semantics > pid = clone(CLONE_FILES); > if (pid == 0) { > fd = seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, &prog); > > // Now this fd will be valid in both parent and child. > // If you haven't blocked it you can inform the parent what > // the fd number is via pipe2(). If you have blocked it you can > // use dup2() and dup to a known fd number. > } But what if your seccomp filter wants to block both pipe2() and dup2()? Whatever syscall you want to use to do this could be blocked by some seccomp policy, which means you might not be able to use this feature in some cases. Perhaps it's unlikely, and we can just go forward knowing this. But it seems like it is worth at least acknowledging that you can wedge yourself into a corner. Tycho