An issue with group based <policy> in dbus daemon

[Markku Savela]

> From: "Colin Walters" <walters at verbum.org>

> Unix groups are nearly useless; the static nature of them is just
> one problem.

Which is why I wanted to use them for something useful...

> Your services can implement access control internally; PolicyKit is
> a library for doing this.

...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.

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.

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]

> 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. Seems, that SELinux would require a
total policy regeneration every time such service is installed. Or,
when an application, which requires multiple permissions in a new
combination, is installed (looks like each permission combination
requires an own domain in SELinux?). Still looking into this...