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

Re: [PATCH 00/12] Add kdbus implementation

From: Daniel Mack <hidden>
Date: 2014-10-30 07:44:17
Also in: lkml

On 10/29/2014 11:28 PM, Andy Lutomirski wrote:
On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman
quoted
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.
Yes, that's true.
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).
Which piece of credential information are you concerned about,
particularly? I might miss something, but AFAICS, all of that
information can be queried by a remote peer anyway, through /proc for
instance. The reason why we (optionally) attach them to messages is that
we want to let the other side know which information was authoritative,
precisely at the time the message was sent. Current implementation can't
do that in a race-free way.

Also note that we currently drop all such metadata whenever a message
crosses a PID or user namespace boundary. This is because we currently
don't know yet which information we would want to transport in such
cases, and how the translation in both directions would look like, from
a semantic perspective. Hence, we decided to leave that for later.

I'll go through your other replies during the day. Thanks for your input
on that RFC, everyone.


Daniel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help