From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 17:51:03 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 913F9258 for ; Sat, 3 Jan 2015 17:51:03 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 68C8864F23 for ; Sat, 3 Jan 2015 17:51:03 +0000 (UTC) Received: from [10.0.1.21] (host86-132-107-174.range86-132.btcentralplus.com [86.132.107.174]) by cyrus.watson.org (Postfix) with ESMTPSA id 500BE46B3F; Sat, 3 Jan 2015 12:51:02 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Disabling ptrace From: Robert Watson In-Reply-To: <20150103142535.GW42409@kib.kiev.ua> Date: Sat, 3 Jan 2015 17:51:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC2F5F5-1C46-453C-80C9-0BCC8884A1A1@FreeBSD.org> References: <20141230111941.GE42409@kib.kiev.ua> <20150102171314.GS42409@kib.kiev.ua> <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> <20150103142535.GW42409@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1993) 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 17:51:03 -0000 On 3 Jan 2015, at 14:25, Konstantin Belousov = wrote: >=20 >> 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. >=20 > Isn't allowing a process to exempt itself from aduting a real security = bug ? Oh, definitely. This was an example, however, of more asynchronous = tracing types and events, where having access to the =E2=80=98tracing = disabled=E2=80=99 state of the originating process might prove = important. For example, if we extended ktrace to support tracing some of = the same sorts of asynchronous events, where full process context = isn=E2=80=99t available, but the events can be cleanly tied back to the = initiating process via a saved credential. >> I???m OK with putting the flag on the process, but frequently the = process credential is where we stick security-related subject/object = flags... >=20 > Should I interpret the statement as agreement, in principle, with the = patch ? As long as it is clearly and carefully documented in the man page that = this is a non-security feature, I=E2=80=99m alright with it being = brought in. We might want to think about how tools such as DTrace, etc, = should report tracing failures when the flag is set. Robert=