From owner-freebsd-dtrace@freebsd.org Thu Jun 15 10:45:39 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 6EE3BD8726A for ; Thu, 15 Jun 2017 10:45:39 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05CD870D72 for ; Thu, 15 Jun 2017 10:45:39 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from host-4-75.office.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 01C779AFC for ; Thu, 15 Jun 2017 10:45:36 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/01C779AFC; dkim=none; dkim-atps=neutral To: freebsd-dtrace@freebsd.org From: Matthew Seaman Subject: Creating a dtrace group? Message-ID: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> Date: Thu, 15 Jun 2017 11:45:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TGPakD5oHjSQNQPgF5VI0ujmD38aLe4tj" 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 10:45:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TGPakD5oHjSQNQPgF5VI0ujmD38aLe4tj Content-Type: multipart/mixed; boundary="Ktr9p4jpPHAOEtf7S5bD8C6UJvGOCSVjd"; protected-headers="v1" From: Matthew Seaman To: freebsd-dtrace@freebsd.org Message-ID: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> Subject: Creating a dtrace group? --Ktr9p4jpPHAOEtf7S5bD8C6UJvGOCSVjd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=3D10] add path dtrace/helper mode 0660 group dtrace # sysrc devfs_system_ruleset=3D"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=3D770(postgres) gid=3D770(postgres) groups=3D770(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? Making postgres and other UIDs used by daemon processes members of the dtrace group will have to be added to individual ports, but that's easy enough. Cheers, Matthew --Ktr9p4jpPHAOEtf7S5bD8C6UJvGOCSVjd-- --TGPakD5oHjSQNQPgF5VI0ujmD38aLe4tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJZQmVQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnvwEP/j5ofKAItK2yD50RQBrzjDc+ 2XUVZnf924ctEZDufw0XE0lgTiiNpKBvVI7KeZKcL5+sdHCMnEDprsjw/1MbbMkH OnqCqwwBbFp6kPAWu0oMuLi0OsAou6kQQwlTiDvDop1cFGWsx5MSbzqUdCCUrjl1 zbbOOljZN/N6ZFy6daMsY7t62Y07Iv1CVnEIHcK7QKJyCN7jqoUdHapTOZlwGRXV w5OPo5kdedr8KEizhYo7dz+9cAKUdx5farRNh8ETvDGt/EBUV62MFTgg3ogZ6vHM rupeH3/uCRrLoIakpa22dWQ8/7A5Is9FX+6P20/vjosWlDrsRSbn2N6tHcmpJB2B lm/gSFGJxvaTI4bNfd/GRnAjk/efuhCjS8L9kg3Pz0si0494i/E2bSRWRPGoSssD ZZaPbv22MXYEZQb3p6N6EcJmnPWUjnWTjmZ6lXa9jHkZJSJ8dnhcFt5qoNhvzzn9 0bhRfU/RdE0cTzwenhCQq1sIouXAYq+GWiwjIy7xnfHkEQ7yADknEgVTXFnfZIZv GjhX3UDwbpiyEnc+udoyLktmqyOKBd/8bK5Z1ugeFQo+tbqDpdPh6vrHERS1KiDV 2sa+kK0OVN8U1ErEij/kPmKHivdL14cxd88f7SpTzMyJrqrBY7oCH9w6t/yn32eS 8ku/kMULU9esywRZsOaY =K3C3 -----END PGP SIGNATURE----- --TGPakD5oHjSQNQPgF5VI0ujmD38aLe4tj-- From owner-freebsd-dtrace@freebsd.org Thu Jun 15 14:16:36 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 6D14CD8B4A8 for ; Thu, 15 Jun 2017 14:16:36 +0000 (UTC) (envelope-from rm@joyent.com) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 3F31C76BF1 for ; Thu, 15 Jun 2017 14:16:36 +0000 (UTC) (envelope-from rm@joyent.com) Received: by mail-pf0-x231.google.com with SMTP id l89so8047870pfi.2 for ; Thu, 15 Jun 2017 07:16:36 -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=vN7firj715HT2IqY+Zku1FlG1Vf9r5DqgTxppBOA5SU=; b=QS1z5QJh0mjicXUZI7znRkyCV/B2gapsU1H2MWVxIgNsvymOM6DxnpD5xRIPFeB3AH GVaj/WylsT2ghXNQu0Fj0vNG4Rt0aOrTvejJcPj6TxGcdp/dr9MSGVNqDyK7/cep5aSO ef5ZNkYRdNDfnQgbVxpB2jN7F5QCM7eFi+zdQ= 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=vN7firj715HT2IqY+Zku1FlG1Vf9r5DqgTxppBOA5SU=; b=Iy7UJxPceNikuhShCVrMcdrk8lT/0uOxD74TaP/qg5STNOxaf1CvNiT5PliApdKajm 6t24qBPImH3Wm5eTb/AGe5eEu50qupzGo6h01ivVUu5jkG7DSRhJG/D/CsuJl0HGYs21 VVgOQuAqM2RQKX1HhM1nDjNxZ+WDYW5Cv5d6Df9OFfSJOhQzxCJX+4WnvqKBT2OeJ0eW nF0a4oRmjiKOn0C0r59hynDhtugF40MWPcQOLafBreynrs2FR/wObMAWyAO+saFhFBwl LMKtfxh7390dDvqhwi2r78iIhwDCezRZvcm3e9lixz7ILXe+cdDup5zbwrDav7DW4f23 nxoA== X-Gm-Message-State: AKS2vOwMuvfE67BBbsOdwWPzd5uvuyMyoArIdZ7g28WKm8gIOBHwFAX3 BKC94sT223tKV5LILQ+Sjg== X-Received: by 10.99.100.135 with SMTP id y129mr5708723pgb.5.1497536195310; Thu, 15 Jun 2017 07:16:35 -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 o2sm574446pgq.44.2017.06.15.07.16.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 07:16:34 -0700 (PDT) Subject: Re: Creating a dtrace group? To: Matthew Seaman , freebsd-dtrace@freebsd.org References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> From: Robert Mustacchi Message-ID: <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> Date: Thu, 15 Jun 2017 07:16:33 -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: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> 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:16:36 -0000 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 From owner-freebsd-dtrace@freebsd.org Thu Jun 15 14:40:34 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 942AAD8B98C for ; Thu, 15 Jun 2017 14:40:34 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EE86775AB for ; Thu, 15 Jun 2017 14:40:34 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from host-4-75.office.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 484C09B38; Thu, 15 Jun 2017 14:40:30 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/484C09B38; dkim=none; dkim-atps=neutral Subject: Re: Creating a dtrace group? To: Robert Mustacchi , freebsd-dtrace@freebsd.org References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> From: Matthew Seaman Message-ID: Date: Thu, 15 Jun 2017 15:40:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xEp8SFMF8BqKlnnVGRd3NHQXWD56TxM9D" 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:40:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xEp8SFMF8BqKlnnVGRd3NHQXWD56TxM9D Content-Type: multipart/mixed; boundary="dLXHSQl1Qlfai7EjOFo6J6USkWUc7vxDb"; protected-headers="v1" From: Matthew Seaman To: Robert Mustacchi , freebsd-dtrace@freebsd.org Message-ID: Subject: Re: Creating a dtrace group? References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> In-Reply-To: <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> --dLXHSQl1Qlfai7EjOFo6J6USkWUc7vxDb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 ge= t >> dtrace working with postgresql during BSDCan. Many thanks to markj an= d >> swills and others for their help. >> >> By default the permissions/ownership on /dev/dtrace/helper look like t= his: >> >> 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 whi= ch >> switches to a non-root uid on startup. Most persistent daemon process= es >> 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=3D10] >> add path dtrace/helper mode 0660 group dtrace >> # sysrc devfs_system_ruleset=3D"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=3D770(postgres) gid=3D770(postgres) groups=3D770(postgres),141(dtr= ace) >> >> 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? >=20 > Hi Matthew, >=20 > 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. >=20 > 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= =2E >=20 > I'm not personally familiar with the FreeBSD privilege model, but seems= > like something you may want to think about, especially if this is comin= g > up in the context of non-privileged users being used for > security-conscious reasons. >=20 > Robert >=20 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: https://wiki.freebsd.org/DTraceTODO Cheers, Matthew --dLXHSQl1Qlfai7EjOFo6J6USkWUc7vxDb-- --xEp8SFMF8BqKlnnVGRd3NHQXWD56TxM9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJZQpxcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnJMEP/job6ppqjJDf+TRvdWYUDeKn eHaaDycUlMmMYaoFoqQZijZ3KdtNSbl/3/PkMJKY+ANZk+QGb02PDAYOSz1VRzwA ssVNfTCw22gbDXXwtKaWg0VfjUCwSUvrHcFNKDOfntt22RMrJ9NazHEAzr9GK14J ucCY8NIU0HLqXHD1no6Zysx4x6YJ7R1fl0KqjMggaeQfzSlRG9EHIFhg3/gbDQAi wWRx64FJ5RgBeJGdhEuhSbB+cAHQ3iQSsLJpn8Q5fQMbzzvfpF2/RacHYgEEeMDU W7e4cBEFGkUtsatkWAARMTYb/VPRZQ7k0ZHci8CsbxBjCimdCmLger9xwM+7kxJO hE2cCesLPhm1vwNicuP2KXP7yyvIiXMk56flOvEHHUfMCg/slqtuOiSecBhhaM4D jO+K/Q5kj4bU0okxASLv33llhHvr0d1JbyMh1Z9NhvD8vqcpt7eCJyv8GOWI9A9D vEUBcOqQewE7dOsG6/QphfOZvYyq32WFVd57sv1QQNUcr0oaXCuWBBeHSXdMnc+P eShrBvK0H9JWMvpS8OuZD9Mm94azlA192ym3ygOn3+aUA30XVGQuWTSfFVAmJdhn H0nYfxSv88RMq6oKUp8KKj7vFgwX/5THZGuPAbYrPRXeYv2eUbFroPOju5vYGDk5 N+bFqh6jB4UejyHRF5j6 =UqbG -----END PGP SIGNATURE----- --xEp8SFMF8BqKlnnVGRd3NHQXWD56TxM9D-- 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