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.
Robert
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
