Off-topic: D-Bus in the kernel

[Ray Strode]

Hi,

On Wed, Oct 6, 2010 at 12:10 PM, Alban Crequy
<alban.crequy at collabora.co.uk> wrote:
> In the same way the ability to send file descriptor in D-Bus message
> with SCM_RIGHTS ancillary data was added in D-Bus 1.3.0, the
> D-Bus protocol could be enhanced to send SCM_CREDENTIALS ancillary data
> (see man unix(7)) with pid, uid and gid.
It uses that stuff now to verify security policy, and provide
GetUnixProcessId etc.

> The value pid+uid+gid sent by
> a process are checked by the kernel, so the process cannot write random
> values.
Well, you actually can spoof that data if you're root, but that's
neither here nor there I guess.

> In your example, packagekitd can run as a privileged user with D-Bus
> activation, auto-started by either 'bob' or 'sally' but when they send
> D-Bus method calls to install and remove packages, packagekitd would
> know which user initiated each request and could log that. It would not
> be the login uid, but maybe it is enough for auditd?
I'm not sure if that meets the needs of the audit folks.  They want
something that userspace can't easily fake.
I'm not sure where the line is, though.

One things clear to me now, if you've got one service serving multiple
clients, that service is the only one that knows when a given client
is being served. It's not something the kernel can really guess or
figure out implicitly without adding more api.

I had a litte conversation with ajax about this a while back:

http://people.freedesktop.org/~halfline/telling-the-kernel-which-client-is-getting-served.txt

(he also needs to be able to tell the kernel when X is serving a
particular client)

--Ray