Creating a dtrace group?

[Robert Mustacchi]

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