Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757636AbaJ2WhJ (ORCPT ); Wed, 29 Oct 2014 18:37:09 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:60078 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751917AbaJ2WhH (ORCPT ); Wed, 29 Oct 2014 18:37:07 -0400 MIME-Version: 1.0 In-Reply-To: References: <1414620056-6675-1-git-send-email-gregkh@linuxfoundation.org> <20141029222531.GA8129@kroah.com> From: Andy Lutomirski Date: Wed, 29 Oct 2014 15:36:44 -0700 Message-ID: Subject: Re: [PATCH 00/12] Add kdbus implementation To: Greg Kroah-Hartman Cc: Linux API , "linux-kernel@vger.kernel.org" , John Stultz , Arnd Bergmann , Tejun Heo , Marcel Holtmann , Ryan Lortie , Bastien Nocera , David Herrmann , Djalal Harouni , simon.mcvittie@collabora.co.uk, daniel@zonque.org, alban.crequy@collabora.co.uk, javier.martinez@collabora.co.uk, Tom Gundersen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 29, 2014 at 3:28 PM, Andy Lutomirski wrote: > On Wed, Oct 29, 2014 at 3:25 PM, Greg Kroah-Hartman > wrote: >> On Wed, Oct 29, 2014 at 03:19:21PM -0700, Andy Lutomirski wrote: >>> On Wed, Oct 29, 2014 at 3:00 PM, Greg Kroah-Hartman >>> wrote: >>> > * 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. > So does the code: + /* + * The first receiver which requests additional + * metadata causes the message to carry it; all + * receivers after that will see all of the added + * data, even when they did not ask for it. + */ + if (conn_src) { + /* Check if conn_src is allowed to signal */ + ret = kdbus_ep_policy_check_broadcast(conn_dst->ep, + conn_src, + conn_dst); + if (ret < 0) + continue; + + ret = kdbus_ep_policy_check_src_names(conn_dst->ep, + conn_src, + conn_dst); + if (ret < 0) + continue; + + ret = kdbus_kmsg_attach_metadata(kmsg, conn_src, + conn_dst); + if (ret < 0) + goto exit_unlock; + } + I'd like this if the sender chose the metadata flags. In fact, I'd want to make that feature available on regular UNIX sockets, too (search the archives for SCM_IDENTITY). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/