Date: Thu, 15 Jun 2017 07:49:10 -0700 From: Robert Mustacchi <rm@joyent.com> To: Matthew Seaman <matthew@FreeBSD.org>, freebsd-dtrace@freebsd.org Subject: Re: Creating a dtrace group? Message-ID: <10d6eb4b-35f3-aa9c-2a26-7d1645686697@joyent.com> In-Reply-To: <d2c70016-44f6-7c74-078c-6cce4199fe92@FreeBSD.org> References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> <d2c70016-44f6-7c74-078c-6cce4199fe92@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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. Roberthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10d6eb4b-35f3-aa9c-2a26-7d1645686697>