DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps

Robert Watson rwatson at FreeBSD.org
Tue Oct 19 10:00:14 UTC 2010

On Tue, 19 Oct 2010, Rui Paulo wrote:

>> you think adding pgsql to wheel might help? cc freebsd-security@ and see 
>> their opinion about the topic.
> dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw 
> access to the /dev/dtrace/helper. I specifically added write access to the 
> wheel group for this.

In the medium term, part of the solution here will be to finish adding a 
role-based privilege system.  I had this on my todo list for 8.0 but didn't 
manage to get it finished.  With any luck, it will make 9.0 in plenty of time. 
this would allow specific kernel privileges to be delegated to specific users 
and groups (among other things).  Many of the kernel changes to support this 
have been done since 7.0 when I added priv(9), but we've not yet selected a 
specific policy and API to bind to them.  Some appliances are already using 
priv(9) via extensible MAC modules to delegate privilege, but for a role-based 
privilege system, I think a tighter integration is preferable (especially in 
light of the risks from composing incorrectly with the root user model).

In some sense, however, a privilege system is also exactly the wrong answer. 
Ideally, you should be able to run dtrace on any process that you have 
debugging rights on, which is calculated with respect to the credentials of 
the two processes involved (subject and object).  You might also reasonably 
key certain kernel probes, such as systrace probes, to the same authorization 
scheme.  The remainder of kernel tracing presumably should remain a privilege, 
as should the use of kernel probes.

In general, I would prefer it if the kernel didn't know any more about 
specific users and groups than it already does -- in practice, this is 
somewhat unavoidable due to the way we do devfs, but minimizing it would be a 
good idea.  In the past, where we have had special things we need to delegate 
that bypass some but not all system integrity protections (such as shutdown, 
reboot, and backup), we've assigned them via the operator group, FYI.


More information about the freebsd-current mailing list