From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 10:00:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712F11065674; Tue, 19 Oct 2010 10:00:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB4B8FC17; Tue, 19 Oct 2010 10:00:09 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D2C2546B45; Tue, 19 Oct 2010 06:00:08 -0400 (EDT) Date: Tue, 19 Oct 2010 11:00:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rui Paulo In-Reply-To: <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> Message-ID: References: <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-15?Q?Istv=E1n?= , freebsd-current , Garrett Cooper Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 10:00:14 -0000 On Tue, 19 Oct 2010, Rui Paulo wrote: >> you think adding pgsql to wheel might help? cc freebsd-security@ and see >> their opinion about the topic. > > dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw > access to the /dev/dtrace/helper. I specifically added write access to the > wheel group for this. In the medium term, part of the solution here will be to finish adding a role-based privilege system. I had this on my todo list for 8.0 but didn't manage to get it finished. With any luck, it will make 9.0 in plenty of time. this would allow specific kernel privileges to be delegated to specific users and groups (among other things). Many of the kernel changes to support this have been done since 7.0 when I added priv(9), but we've not yet selected a specific policy and API to bind to them. Some appliances are already using priv(9) via extensible MAC modules to delegate privilege, but for a role-based privilege system, I think a tighter integration is preferable (especially in light of the risks from composing incorrectly with the root user model). In some sense, however, a privilege system is also exactly the wrong answer. Ideally, you should be able to run dtrace on any process that you have debugging rights on, which is calculated with respect to the credentials of the two processes involved (subject and object). You might also reasonably key certain kernel probes, such as systrace probes, to the same authorization scheme. The remainder of kernel tracing presumably should remain a privilege, as should the use of kernel probes. In general, I would prefer it if the kernel didn't know any more about specific users and groups than it already does -- in practice, this is somewhat unavoidable due to the way we do devfs, but minimizing it would be a good idea. In the past, where we have had special things we need to delegate that bypass some but not all system integrity protections (such as shutdown, reboot, and backup), we've assigned them via the operator group, FYI. Robert