Thread (89 messages) flat view 89 messages, 18 authors, 2014-11-17

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help