An issue with group based <policy> in dbus daemon

[Colin Walters]

On Tue, Aug 5, 2008 at 5:29 AM, Markku Savela <msa at moth.iki.fi> wrote:

>
> ...which is more targeted for a desktop and defining the access rights
> again based on UID's. And the checking solution involves heavy
> operations using setgid helper programs to access the "hidden"
> permission database.


Right, PolicyKit is for defining "coarse" access control; but if you need
high performance, one option might be to have a PolicyKit mechanism which
hands back the path to a direct unix domain socket.


> I was thinking about a solution, where "permission tokens" are
> preloaded into the process context at the start (by a privileged
> application starter, which controls the policy), and use dynamically
> generated group id's as permission tokens.


I'm not sure we can control all of the ways in which applications get
launched very easily.

Checking access rights of a client in the server would simply reduce
> to verifying that the client process context has the required
> permission token (group identifier). The DBUS modification comes into
> picture, because many services are behind a DBUS messages and I want
> first solution that would not require any changes into server
> implementations.
>
> Of course, some services can do the check themselves. [However, I
> surely wish that DBus daemon would pass the client PID automatically
> in every message -- getting it via separate DBus query causes lot of
> extra work per service call]
>

That's possible.  More generally we could pass the "credentials" along with
a message, including the SELinux security context for example.

But again I think that the pattern of having an access-controlled method
which gives you a token to access a separate high-performance channel makes
sense if you really need high performance.

DBus itself is not designed with performance as the #1 goal.


> > You'd have to describe more of what the problem you're trying to
> > solve is for me to advise; but if your system has a targeted
> > profile, SELinux gives you very strong controls over the entire
> > system security.  The policy language allows you to define which
> > programs can communicate over the system and session bus.
>
> SELinux is an option, but the configuration is scary. Especially, if
> the goal is to allow an installed service daemon to specify own
> permisson tokens for the services.


Part of the realization driven by SELinux is that security really *is* a
whole-system concept; you can't look at individual things in isolation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20080805/fcfa048d/attachment.html