Date: Thu, 15 Jun 2017 15:40:21 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: Robert Mustacchi <rm@joyent.com>, freebsd-dtrace@freebsd.org Subject: Re: Creating a dtrace group? Message-ID: <d2c70016-44f6-7c74-078c-6cce4199fe92@FreeBSD.org> In-Reply-To: <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xEp8SFMF8BqKlnnVGRd3NHQXWD56TxM9D Content-Type: multipart/mixed; boundary="dLXHSQl1Qlfai7EjOFo6J6USkWUc7vxDb"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: Robert Mustacchi <rm@joyent.com>, freebsd-dtrace@freebsd.org Message-ID: <d2c70016-44f6-7c74-078c-6cce4199fe92@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d2c70016-44f6-7c74-078c-6cce4199fe92>