From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 14:25:41 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD835147; Sat, 3 Jan 2015 14:25:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F2FA1F1B; Sat, 3 Jan 2015 14:25:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t03EPZIC019099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2015 16:25:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t03EPZIC019099 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t03EPZ1H019047; Sat, 3 Jan 2015 16:25:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Jan 2015 16:25:35 +0200 From: Konstantin Belousov To: Robert Watson Subject: Re: Disabling ptrace Message-ID: <20150103142535.GW42409@kib.kiev.ua> References: <20141230111941.GE42409@kib.kiev.ua> <20150102171314.GS42409@kib.kiev.ua> <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 14:25:41 -0000 On Sat, Jan 03, 2015 at 01:37:33PM +0000, Robert Watson wrote: > On 2 Jan 2015, at 17:13, Konstantin Belousov wrote: > > > WRT putting the trace-disabled indicator into the credentials, instead > > of just having it as a process attribute, I am not sure that this is > > useful thing. Do you propose to modify existing ucred for the process, > > effectively applying the notrace policy to the whole set of processes > > sharing the credential, or do COW for ucred on disable ? If not COW, > > then the set of the affected processes is somewhat random and too wide. > > If COW, I do not see much practical difference with the per-process > > bit, esp. due to the execve(2) handling. > > > > Also, I am puzzled by reference to an async context. > > Could you provide explicit examples where we do such tracing ? > > It???s less about what we do do, and more about what we perhaps should be doing. I had two things vaguely in mind, neither of which is a perfect match: > > (1) Normally, we expose the data from synchronous read(), write(), send(), and recv() operations using ktrace ??? but we don???t currently do this for asynchronous I/O calls. We likely should, in which case I was pondering which of the asynchronously available bits of state we might want to use for it. In principle, we have both the calling process and credential available, so there, the process would be fine. > > (2) For other kinds of tracing ??? specifically, for the audit trail ??? we make use of saved credentials in a number of cases, and store audit-related filtering data (not so dissimilar from a no-trace flag in some ways) in the credential for this reason. While you are not proposing limiting auditing using this process flag, I think there are a number of structural similarities here that could suggest a similar approach. > > In general, we had always planned to allow auditing of far more asynchronous events than we currently do ??? e.g., firewall events triggered asynchronously by system-call behaviour. We also had loose plans to allow auditing of NFS-originated RPCs, although those are arguably fairly synchronous and not so dissimilar to system calls in various ways. Isn't allowing a process to exempt itself from aduting a real security bug ? > > I???m OK with putting the flag on the process, but frequently the process credential is where we stick security-related subject/object flags... Should I interpret the statement as agreement, in principle, with the patch ?