Date: Tue, 19 Oct 2010 11:00:08 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Rui Paulo <rpaulo@freebsd.org> Cc: =?ISO-8859-15?Q?Istv=E1n?= <leccine@gmail.com>, freebsd-current <freebsd-current@freebsd.org>, Garrett Cooper <gcooper@freebsd.org> Subject: Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps Message-ID: <alpine.BSF.2.00.1010191055420.82536@fledge.watson.org> In-Reply-To: <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org> References: <AANLkTi=BTfcPYtO7Hby3dK7C7qiH2CXdThYyV9QBj8_T@mail.gmail.com> <DE0D21FF-0E8F-4993-87B0-69B7AA74861C@FreeBSD.org> <AANLkTins6w0znaw%2BvQ7M57cSXS1OK6aQ0KUyJMjD-ytq@mail.gmail.com> <7EC03A5E-61DA-46AB-95E1-1D844E10C735@FreeBSD.org> <AANLkTingZ1uQiC3TYaJtgQFG_m1HOAsOdCtRx4Aizj_i@mail.gmail.com> <D4CE1F20-02ED-4267-95D2-0199AEFA7C43@freebsd.org> <AANLkTinvBDQt-4Pk-GN3P1Wa20UTbr7OJaXiQeSD375u@mail.gmail.com> <FA2F29D4-F8E8-41A6-A471-DFE36C677B0D@freebsd.org> <AANLkTikZCUbwPF-grkAWQLVSL%2Bnm_NDBP%2B6ZLyYBNZxs@mail.gmail.com> <AANLkTimf%2B4xPLmYyrA%2B2GkYsRaNiLZjeAxEBL7MFd2Hk@mail.gmail.com> <AANLkTimFOKbix2bS0wQanGGv_jrysWm=kxu-FAEGd3g6@mail.gmail.com> <0B32E6BF-8CFE-4BC3-AFC8-EA77B1B5E8D7@freebsd.org> <AANLkTimqQESoHdzytUphBxTS8FYR6qiYeT3nfds2GJhU@mail.gmail.com> <28FFE6A7-0ECD-4454-9364-DC555327678E@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1010191055420.82536>