From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 13:37:36 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 C050A586 for ; Sat, 3 Jan 2015 13:37:36 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 9A486179E for ; Sat, 3 Jan 2015 13:37:36 +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 0F77446B0D; Sat, 3 Jan 2015 08:37:34 -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: <20150102171314.GS42409@kib.kiev.ua> Date: Sat, 3 Jan 2015 13:37:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> References: <20141230111941.GE42409@kib.kiev.ua> <20150102171314.GS42409@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 13:37:36 -0000 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. >=20 > Also, I am puzzled by reference to an async context. > Could you provide explicit examples where we do such tracing ? It=E2=80=99s 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 =E2=80=94 but we don=E2=80=99t = 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 =E2=80=94 specifically, for the audit = trail =E2=80=94 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 =E2=80=94 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. I=E2=80=99m OK with putting the flag on the process, but frequently the = process credential is where we stick security-related subject/object = flags... Robert=