New policy type to check client credentials?

[Markku Savela]

> From: Colin Walters <walters at verbum.org>
> On Thu, Jan 29, 2009 at 8:34 AM, Markku Savela <msa at moth.iki.fi> wrote:
> >
> > On August 4th 2008, I posted a message with topic "An issue with group
> > based <policy> in dbus daemon". ...
> 
> Have you looked at PolicyKit?

Yes, I'm aware of it.

> Using PolicyKit or something like it, i.e. message checks on the
> service side, you can implement whatever you want.

Exactly, this is the basic model: the service is ultimately
responsible for the access control. The rationale for the DBus based
access control is

- there are large number of services using the DBus, none of which
  makes any access control (does Telepathy framework do any nowadays?)

- to avoid the need to modify all those services, I would "allow" the
  service to delegate the access control checking to the DBus.

> For example if you want to poke at a Linux-kernel specific
> credential (assuming your process has the privilege to do so) it
> should be quite straightforward to do.

Reading the subset of the credentials I'm proposing does not need any
special OS privileges. The issue is just that the current kernel does
not have proper API for it. This is another thing I wish to fix.

> You can retrieve the pid of the process using the bus
> GetUnixProcessID API, and from there poke into /proc or make
> whatever system call.

Yes this would work, but the solution is more prone to race
conditions. At least, when the DBus makes the credentials retrieval
(at client connect time), the socket exists and it is more likely that
the associated PID is still valid. Also, the credentials of associated
with the PID are more likely to be what the client desires. In my
model, the client (some privileged daemon) might dowgrade the
credentials after making the DBus connection, but I wish the DBus
policy check to be based on the state that was valid at connect time.

> Finally other major advantages of PolicyKit is that it is more
> explicitly designed for system administrators to customize, and
> better interact with graphical interfaces.

Small devices, like mobile phones, internet tablets and similar
consumer devices, do not really have a concept of "system
administrator" (for majority of the users of such devices). Or, one
could say, the system is administered remotely via software
updates. So, we need to automate all these policy configuration
issues. (*)

> So a good path forward may be to patch PolicyKit to be able to make
> use of the extended-group or other capability checks you'd like.

My hope is to make "libcreds" (or something equivalent) a standard
component of the distributions. Both DBus policy checking and
PolicyKit could probably take advantace of such standard library.

(*) I'm also planning to use some extra annotations in introspect
XML's that define the API's. The DBus-policy file can be generated
automaticly based on the annotations.

A more radical idea would be, that a service could just load the
access control policy to the DBus for it's API's when it starts (send
some message over the service connection to DBus). The traditional
DBus policy would still be needed for some aspects, like controlling
who can own the service name.