Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758941AbaJ3JG7 (ORCPT ); Thu, 30 Oct 2014 05:06:59 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:39520 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758311AbaJ3JG4 (ORCPT ); Thu, 30 Oct 2014 05:06:56 -0400 Date: Thu, 30 Oct 2014 10:06:52 +0100 From: Djalal Harouni To: Andy Lutomirski Cc: "Eric W. Biederman" , Greg Kroah-Hartman , Linux API , "linux-kernel@vger.kernel.org" , John Stultz , Arnd Bergmann , Tejun Heo , Marcel Holtmann , Ryan Lortie , Bastien Nocera , David Herrmann , Simon McVittie , daniel@zonque.org, alban.crequy@collabora.co.uk, Javier Martinez Canillas , Tom Gundersen Subject: Re: kdbus: add connection, queue handling and message validation code Message-ID: <20141030090652.GA2773@dztty> References: <1414620056-6675-1-git-send-email-gregkh@linuxfoundation.org> <1414620056-6675-6-git-send-email-gregkh@linuxfoundation.org> <87k33iw759.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 29, 2014 at 08:55:58PM -0700, Andy Lutomirski wrote: > On Wed, Oct 29, 2014 at 8:47 PM, Eric W. Biederman > wrote: > > Greg Kroah-Hartman writes: > > > >> From: Daniel Mack > >> > >> This patch adds code to create and destroy connections, to validate > >> incoming messages and to maintain the queue of messages that are > >> associated with a connection. > >> > >> Note that connection and queue have a 1:1 relation, the code is only > >> split in two parts for cleaner separation and better readability. > > > > You are not performing capability checks at open time. > > > > As such this API is suceptible to a host of file descriptor passing attacks. > > To be fair, write(2) doesn't work on these fds, so the usual attacks > don't work. But who knows what absurd things kdbus clients will do > with fd passing? Yes, we use ioctl() so we are safe here! if there is a a suid process that does perform arbitrary ioctl() on intrusted passed fds, then we are already in truble given all the already available ioctl() (not only kdbus, all available ioctl()... we blame the client), so yes usual write()/read() do not work here. But we do perform the creds check against the cred of connection creation time, if you open the fd you do not have the connection, you still need a KDBUS_CMD_HELLO ioctl() on the fd, and during that time we store the creds, and we perform all the TALK, SEE and OWN against those creds (uid/gid). It is like a second connect() call, unless you perform the KDBUS_CMD_HELLO you are not connected, and after turning your fd to a connection, a service can restrict its access (TALK, OWN and SEE) policies, not all connected peers can TALK (send messages) to a service. -- Djalal Harouni http://opendz.org -- 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/