Re: [PATCH 00/12] Add kdbus implementation
From: Andy Lutomirski <luto@amacapital.net>
Date: 2014-10-29 22:28:49
Also in:
lkml
On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman [off-list ref] wrote:
On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote:quoted
On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman [off-list ref] wrote:quoted
* Attachment of trustable metadata to each message on demand, such as the sending peer's timestamp, creds, auxgroups, comm, exe, cmdline, cgroup path, capabilities, security label, audit information, etc, each taken at the time the sender issued the ioctl to send the message. Which of those are actually recorded and attached is controlled by the receiving peer.I think that each piece of trustable metadata needs to be explicitly opted-in to by the sender at the time of capture. Otherwise you're asking for lots of information leaks and privilege escalations. This is especially important given that some of the items in the current list could be rather sensitive.You do have to opt-in for this information at time of capture, so I don't understand the issue here. This is the same type of thing that dbus does today, and I don't see the information leaks happening there, do you?
The docs suggest that the *receiver* opts in. I don't think that current dbus has severe information leaks because the total scope for information transparently sent to dbus is rather small (struct ucred only, presumably). --Andy