From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15DFBC71122 for ; Fri, 12 Oct 2018 20:02:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D1EE520868 for ; Fri, 12 Oct 2018 20:02:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=tycho-ws.20150623.gappssmtp.com header.i=@tycho-ws.20150623.gappssmtp.com header.b="ChM4m4T1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1EE520868 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tycho.ws Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbeJMDga (ORCPT ); Fri, 12 Oct 2018 23:36:30 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:45763 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726697AbeJMDga (ORCPT ); Fri, 12 Oct 2018 23:36:30 -0400 Received: by mail-pl1-f194.google.com with SMTP id y15-v6so6400965plr.12 for ; Fri, 12 Oct 2018 13:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho-ws.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vdPSDV1B51J0pwMLq40tWD88fqUwXxbWUb+50kgxuLY=; b=ChM4m4T1i7GmucBU/JzgZcdOBchmQMqV863MHvfTtOF4s+NnnLc265AvTnM96PjZT5 WbQwbeC0yfsIXLgkmthuurYIB75taeGLI6vpqi/lwf3/s900+Tmajz93MaNSCUu+ucZb ERyg95dOq3h4e9WHPn9BQYj7PD9lKK/1dym1Z+UdoJ4t1/kNr8As+d5xA6Oj3vyPOKQ5 CkWICxcewCPGYcMaHABsvuUvgmEvnCDRSY+Gl5v3+pnXa2Gi6xKTS4fnpRWWIE6EcU4Y rr6xYYB3f5pjFCQTp2kXsdDJ1so6YuSOZLJU4BrFqeT+VkRMeI/uCQO+bmtbnBQ2wMqD UsCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vdPSDV1B51J0pwMLq40tWD88fqUwXxbWUb+50kgxuLY=; b=Wx5/P0bkccwVl+YA4b4t/LqE9YCu2uP7LSOaZq01PP76eJSKbNMW9iBb9kLEyHsvfk WcDy8NXPbh/mx8GN2ShQ+Hn6Vs1tk4lDALbHaOZM5KsCk25j+ypkqYZhdWSkifqhrxKQ 0Lg5wP+L/0C8lJmDnfrCxwMV0ypst/VHRdOSxQgy3EECrVop3o5GffQYVubQTT5iYv9T mtYieodJB87wz3gZ2ZKX4WQPjSc6AjvMEv3X2707o/mtEM3Ua7pR7ffz6zgckMzrKb/0 LGiZSGvJ0dDMA9wCiIeR6+/IvfsoDqNh2kP0PPDMQswdfkT0UGhPOw84KDy3ifyjEDQY pEVg== X-Gm-Message-State: ABuFfoh8eTKVCUPvX6mp8aHgVIGKf0Qn/NjGG+bYsi+zD0B2zYNI0RGc AcjA9nhlyLA1F9ByqakmawpUsA== X-Google-Smtp-Source: ACcGV63kYvoDYx3c4gGc5V+dnS9PX9Zaf4WDN9ntwJ2Q1nx/EjA/Q57lSDzO93IlzSprxxNCt9xyeA== X-Received: by 2002:a17:902:2:: with SMTP id 2-v6mr7334285pla.178.1539374542955; Fri, 12 Oct 2018 13:02:22 -0700 (PDT) Received: from cisco ([128.107.241.177]) by smtp.gmail.com with ESMTPSA id q25-v6sm3658697pfk.154.2018.10.12.13.02.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Oct 2018 13:02:21 -0700 (PDT) Date: Fri, 12 Oct 2018 13:02:20 -0700 From: Tycho Andersen To: Andy Lutomirski Cc: Paul Moore , Jann Horn , Christian Brauner , Kees Cook , Linux API , Linux Containers , Akihiro Suda , Oleg Nesterov , LKML , "Eric W. Biederman" , Linux FS Devel , Christian Brauner , LSM List , SELinux-NSA , Stephen Smalley , Eric Paris Subject: Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace Message-ID: <20181012200220.GC5530@cisco> References: <20181008181815.pwnqxngj22mhm2vj@brauner.io> <20181009132850.fp6yne2vgmfpi27k@brauner.io> <16662034750.2781.85c95baa4474aabc7814e68940a78392@paul-moore.com> <1666564e4f8.2781.85c95baa4474aabc7814e68940a78392@paul-moore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Oct 11, 2018 at 06:02:06PM -0700, Andy Lutomirski wrote: > On Thu, Oct 11, 2018 at 4:10 PM Paul Moore wrote: > > > > On October 11, 2018 9:40:06 AM Jann Horn wrote: > > > 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, since they probably have opinions on this > > >>>> > > >>>> I just spent about twenty minutes working my way through this thread, > > >>>> and digging through the containers archive trying to get a good > > >>>> understanding of what you guys are trying to do, and I'm not quite > > >>>> sure I understand it all. However, from what I have seen, this > > >>>> approach looks very ptrace-y to me (I imagine to others as well based > > >>>> on the comments) and because of this I think ensuring the usual ptrace > > >>>> access controls are evaluated, including the ptrace LSM hooks, is the > > >>>> right thing to do. > > >>> > > >>> Basically the problem is that this new ptrace() API does something > > >>> that doesn't just influence the target task, but also every other task > > >>> that has the same seccomp filter. So the classic ptrace check doesn't > > >>> work here. > > >> > > >> Due to some rather unfortunate events today I'm suddenly without easy access to the kernel code, but would it be possible to run the LSM ptrace access control checks against all of the affected tasks? If it is possible, how painful would it be? > > > > > > There are currently no backlinks from seccomp filters to the tasks > > > that use them; the only thing you have is a refcount. If the refcount > > > is 1, and the target task uses the filter directly (it is the last > > > installed one), you'd be able to infer that the ptrace target is the > > > only task with a reference to the filter, and you could just do the > > > direct check; but if the refcount is >1, you might end up having to > > > take some spinlock and then iterate over all tasks' filters with that > > > spinlock held, or something like that. > > > > That's what I was afraid of. > > > > Unfortunately, I stand by my previous statements that we still probably want a LSM access check similar to what we currently do for ptrace. > > > > I would argue that once "LSM" enters this conversation, it just means > we're on the wrong track. Let's try to make this work without ptrace > if possible :) The whole seccomp() mechanism is very carefully > designed so that it's perfectly safe to install seccomp filters > without involving LSM or even involving credentials at all. In a last ditch effort to save the ptrace() interface: can we just only allow it when refcount_read(filter->usage) == 1? Tycho