Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756809AbbDVByi (ORCPT ); Tue, 21 Apr 2015 21:54:38 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:34605 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756783AbbDVByf (ORCPT ); Tue, 21 Apr 2015 21:54:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150413190350.GA9485@kroah.com> <8738434yjk.fsf@x220.int.ebiederm.org> <87lhhv36je.fsf@x220.int.ebiederm.org> <20150414175534.GB3974@kroah.com> <87oamhmbso.fsf_-_@x220.int.ebiederm.org> From: Andy Lutomirski Date: Tue, 21 Apr 2015 18:54:13 -0700 Message-ID: Subject: Re: Issues with capability bits and meta-data in kdbus To: Linus Torvalds Cc: "Eric W. Biederman" , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , Linux Kernel Mailing List , 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: 2331 Lines: 50 On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds wrote: > On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman > wrote: >> - Access to the capability bits is guarded with PTRACE_MAY_READ >> kdbus does not honor that and thus leaks information. > > Now, this is likely not a real problem. > > Yes, when you try to read other processes capabilities, you need > PTRACE_MAY_READ to see them. HOWEVER, that's not really what a kdbus > message would do - it doesn't "read somebody elses capabilities". When > you do a kdbus write, you export your *own* capabilities. If you don't > want others to know what privileges you have, then you shouldn't be > using kdbus. > > It's like saying "you need PTRACE_MAY_READ" to be able to read the > process image of another process. True. But if that other process does > a "write()" system call, then the written data will contain the data > from that process. That's how write works. There's an interesting philosophical question here. If kdbus were a general purpose IPC tool and if the libraries would expose nice knobs like "set this flag if and only if you want to assert CAP_WHATEVER to the server", then maybe this would be okay. But I don't believe that for a second. AFAICS sd-bus (maybe the primary implementation) will always set that flag if for no other reason than that it *doesn't know* when the client is trying to assert a capability. So we'd be giving users a gun which is, in practice, only ever pointed at the users' feet. It's a little worse than that, since this gun also shoots cap_permitted, cap_inheritable, and bset bullets, none of which seem usable for anything other than foot-shooting even in the best case. And don't even get me started about some of the other metadata items. All of this completely ignores the fact that selinux can and does restrict access to /proc and kdbus will never respect those restrictions. Also, I'd like to see us move closer to a world where real distros set hide_pid=1, and this is a big step in the opposite direction. --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/