Creating a dtrace group?

[Robert Mustacchi]

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