Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964799AbbD0NB6 (ORCPT ); Mon, 27 Apr 2015 09:01:58 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:36311 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964778AbbD0NBx (ORCPT ); Mon, 27 Apr 2015 09:01:53 -0400 Date: Mon, 27 Apr 2015 14:01:47 +0100 From: Djalal Harouni To: Andy Lutomirski Cc: Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) Message-ID: <20150427130147.GA5315@dztty> References: 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 Content-Length: 2379 Lines: 47 On Thu, Apr 23, 2015 at 12:41:18PM -0700, Andy Lutomirski wrote: > On Thu, Apr 23, 2015 at 11:48 AM, Linus Torvalds > wrote: > > On Thu, Apr 23, 2015 at 10:57 AM, Linus Torvalds [...] > Objection 2: There's a difference between the printer daemon knowing > that Angry Penguins has general permission to print and an explicit > assertion by Angry Penguins of its permission to print. Suppose that > printing is implemented by having Angry Penguins call the method Write > on some kdbus thing. Suppose further that changing root's password is > implemented by having the caller call the method Write on some other > kdbus thing. Before changing the password, the password daemon makes > sure that the caller (or the caller's kdbus conn or whatever) has > password-changing permissions. Before printing, the printer daemon > makes sure that the caller has printing permissions. > > In kdbus, this is IMO a big problem. See, I can try to find some > setuid root program that takes a printer object as input (however > kdbus might do this -- presumably it would be an object name) and > calls Write to print some diagnostic thing. Now I just feed it the > password-changing thingy as input and I can get it to "print" to the > root password. Oops. This will not only introduce complexity, it is formulated for a "supposed" problem, and even if this problem exists, the fix _should_ be simple, no reason to add the extra complexity. A suid root program that takes objects from input without assuming that the unprivileged user has provided this, is a bogus program and the fix should be at this layer, _not_ introduce extra layers... The same thing can be applied on every other part of the kernel, what if a suid program takes some input, constructs objects/structs based on that, and makes a direct syscall or one through a library into another part of the kernel ? I don't see why it is a problem for kdbus since this supposed problem can affect every major part of the kernel. If there is something to fix here, then sure it is not at this level. Thanks! -- 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/