From owner-freebsd-dtrace@freebsd.org Thu Jun 15 14:49:13 2017 Return-Path: Delivered-To: freebsd-dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C7DAD8BEDA for ; Thu, 15 Jun 2017 14:49:13 +0000 (UTC) (envelope-from rm@joyent.com) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E704D77B4E for ; Thu, 15 Jun 2017 14:49:12 +0000 (UTC) (envelope-from rm@joyent.com) Received: by mail-pf0-x22e.google.com with SMTP id s66so8464006pfs.1 for ; Thu, 15 Jun 2017 07:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joyent.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V2Zlr44XI9S34WuNgneBvFdsYVqhF2nS4kBBPdoWsww=; b=JHgQLy/YD6VptdhCP6V/lqozNAcar7I1RK375pxbPmBZk0NW+UfNwWdIVpHqeq0Z1N hwv1g7Smu5d1DZy90HYrt8R2aW58f61t134fqVchSUgnzziLz2xpDzpLy0v7RDVs7ZYJ p617ZpZ/+2YzgqqI3R4/ncE2lpLf0+lPZX3+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V2Zlr44XI9S34WuNgneBvFdsYVqhF2nS4kBBPdoWsww=; b=to9MgEIR4H+CIiS1aOyS9mEIoAEdFve+BmRC1bWqsvAkvOCkzPK6NkX8MzeAWCO79E eaFU8ytMeMB6s0ynku+Xu2bQPdP3pDTmRHQMIXnWsa6QMO2ZTGzPdm4XjPo/lB2SC4ub Y2l+a3HKoyJvhhWZtb9hszwpzrWoopMiSaJLXwJ85yOn+33/QKlrEQhxOARQILB1zMz+ e85OnLed7LBoaSITAILr4NklmqNpKEgZgkcHa0vUHOsF5wEmbd8m0kKVCfwSGsIRTY0I Jyk6SRlL0VsxVMnJz931CePJIVV55YNNVIpFIk/qN6lJ9ugTS9um8Q4iyLMtGmYPDwuh fJHQ== X-Gm-Message-State: AKS2vOziHM1AU27MZDAkP6Uk+zOzjpuxQzh/LYRbDM1ERhBmp5aFofQN u5bMlpKWpBj+562FD2gk3g== X-Received: by 10.99.44.201 with SMTP id s192mr5740448pgs.84.1497538152121; Thu, 15 Jun 2017 07:49:12 -0700 (PDT) Received: from zanarkand.local (c-73-241-83-139.hsd1.ca.comcast.net. [73.241.83.139]) by smtp.gmail.com with ESMTPSA id b1sm724930pfl.70.2017.06.15.07.49.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 07:49:11 -0700 (PDT) Subject: Re: Creating a dtrace group? To: Matthew Seaman , freebsd-dtrace@freebsd.org References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> From: Robert Mustacchi Message-ID: <10d6eb4b-35f3-aa9c-2a26-7d1645686697@joyent.com> Date: Thu, 15 Jun 2017 07:49:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:49:13 -0000 On 6/15/17 7:40 , Matthew Seaman wrote: > On 2017/06/15 15:16, Robert Mustacchi wrote: >> On 6/15/17 3:45 , Matthew Seaman wrote: >>> This is something that came up while I was flailing about trying to get >>> dtrace working with postgresql during BSDCan. Many thanks to markj and >>> swills and others for their help. >>> >>> By default the permissions/ownership on /dev/dtrace/helper look like this: >>> >>> crw-rw---- 1 root wheel 0x5 Jun 3 11:42 helper >>> >>> In order to dtrace a userland application it needs read/write access to >>> that device. Now, that's not the case for example with postgresql which >>> switches to a non-root uid on startup. Most persistent daemon processes >>> with network access will do this for obvious security reasons.> >>> The effect is that running 'dtrace -l -m postgres' shows no available >>> probes. >>> >>> One solution is to create a new 'dtrace' unix group, which the userids >>> those daemons run under can be added to, and make /dev/dtrace/helper >>> owned by that group. Like so: >>> >>> # pw group add -n dtrace -g 141 -M postgres >>> # cat /etc/devfs.rules >>> [userdtrace=10] >>> add path dtrace/helper mode 0660 group dtrace >>> # sysrc devfs_system_ruleset="userdtrace" >>> >>> (GID 141 is just the first available from /usr/ports/GIDs) This make >>> /dev/dtrace/helper look like so: >>> >>> crw-rw---- 1 root dtrace 0x5 Jun 3 11:42 helper >>> >>> and the postgres user account: >>> >>> # id postgres >>> uid=770(postgres) gid=770(postgres) groups=770(postgres),141(dtrace) >>> >>> Would it be possible to create a dtrace group like this in the default >>> /etc/group and change the devfs settings so that /dev/dtrace/helper is >>> group owned by the new dtrace by default? Preferably if this could go >>> into the upcoming 11.1 and 10.4 releases? >> >> Hi Matthew, >> >> Have you looked at the DTrace privilege model? If you haven't, it seems >> worth pointing out that DTrace has a notion of different privilege >> levels that are tied into different probes. Though this has never been >> ported over into FreeBSD. >> >> We use this a lot in illumos to solve problems like this. Importantly, >> for example, kernel probes require different privileges from USDT / pid >> probes. This means, for example, that destructive actions that can >> modify kernel memory can be taken away from things that just want to >> look at user land probes. In illumos, it also ties into privileges >> around what processes a user is allowed to see and modify (think what >> can I attach a debugger to), which helps from a notion of multi-tenancy. >> >> I'm not personally familiar with the FreeBSD privilege model, but seems >> like something you may want to think about, especially if this is coming >> up in the context of non-privileged users being used for >> security-conscious reasons. >> >> Robert >> > > Isn't that solving a somewhat different problem? As I understand it, > dtrace privileges is all about enabling a non-privileged user to run > dtrace but limiting what they can access through it. > > Here we're expecting to need root privileges to run dtrace at all, but > the traced process itself needs different permissions in order for the > tracing to work. AFAIK on FreeBSD you have to run dtrace as root -- at > least, there are still items on the ToDo list about that: Hey Matthew, Sorry, I missed the fact that this was specific to the helper device. For what it's worth, the device is 666 on illumos and OS X. Robert