Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030453AbbDWR5m (ORCPT ); Thu, 23 Apr 2015 13:57:42 -0400 Received: from mail-ig0-f170.google.com ([209.85.213.170]:34485 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030437AbbDWR5i (ORCPT ); Thu, 23 Apr 2015 13:57:38 -0400 MIME-Version: 1.0 In-Reply-To: <20150423171640.GA11227@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> Date: Thu, 23 Apr 2015 10:57:37 -0700 X-Google-Sender-Auth: mdQ4oGQk0FR1LNDbzs-1ll8ZRZg Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: Linus Torvalds To: Greg Kroah-Hartman Cc: Andy Lutomirski , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3608 Lines: 78 On Thu, Apr 23, 2015 at 10:16 AM, Greg Kroah-Hartman wrote: >> >> - starttime, cmdline, and possibly other pieces of metadata are also >> problematic. I think starttime is especially bad because it both >> breaks CRIU and is IMO completely unnecessary -- I sent out draft >> "highpid" patches a while ago to give a much better alternative that >> isn't racy and won't break CRIU. But cmdline is also IMO ridiculous. > > starttime was removed a while ago, are you sure you are looking at the > latest code? > > cmdline has been discussed and it really helps with debugging. > Decisions aren't being made based on it. Quite frankly, I personally find cmdline/comm etc *much* worse than sending the capabilities. The whole notion of knowing "the other end is root" (or more specifically some capability like "the other end can access raw hardware") I think is a thing that absolutely makes sense in any communication channel. I really don't even see why it would be conditional. I mean, it's not exactly a secret anyway, and it just makes *sense* for any protocol that may end up doing operations _for_ the recipient. Same goes for uid etc - if you are implementing a service daemon, the uid of the requester sure as hell makes a ton of difference in what you might want to expose. Things like "does this user have access rights to the printer?" are very natural questions to ask. So I really don't understand why that part is even controversial. kdbus wasn't meant to be some generic IPC mechanism. It is meant as a way to talk to system daemons. So the whole "capabilities and user information" is really to me a non-issue. It's clearly required information, and if you don't want to expose it, you damn well have absolutely *zero* business talking to system daemons. Really, it's that simple. But things like "comm" and the cmdline? That makes me nervous. There are real privacy issues there. Sure, maybe you think it's useful for debugging, but the very fact that you think it's useful for debugging makes me suspect you might be logging it (for future debugging). And quite frankly, I don't think you should be logging things like that. Yes, yes, if you're a system admin, you can find those things out, but they should *not* be something that you just end up logging by mistake or because "it's easy and all the information is right there". If somebody is printing something, it shouldn't matter if it's "lpr" or "firefox http://horses.and.trannyporn.my.little.pony.com/" that does the printing. And you can go "but we don't log it" all you want. It's still a bad idea. Sane people should refuse to allow a system service to see those kinds of things by default, for a very simple reason: it's none of their business. So I'd suggest just getting rid of "tid_comm/pid_comm/cmdline". There is no possible valid excuse for them. They aren't trustworthy anyway (ie a real attacker can obfuscate them easily), and they *are* potentially sensitive. [ Side note: the tid_comm/pid_comm ones depend on TASK_COMM_LEN anyway, which might change. a 16-byte command name used to be insanely long in the traditional unix environment, but these days it's actually regularly a truncated name due to programs called things like "gnome-shell-extension-prefs" or "abrt-action-generate-core-backtrace". ] Linus -- 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/