Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933346AbbDVLlJ (ORCPT ); Wed, 22 Apr 2015 07:41:09 -0400 Received: from mail-qg0-f47.google.com ([209.85.192.47]:34449 "EHLO mail-qg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932826AbbDVLlG (ORCPT ); Wed, 22 Apr 2015 07:41:06 -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> Date: Wed, 22 Apr 2015 13:41:05 +0200 Message-ID: Subject: Re: Issues with capability bits and meta-data in kdbus From: David Herrmann To: Linus Torvalds Cc: "Eric W. Biederman" , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , Andy Lutomirski , Linux Kernel Mailing List , Daniel Mack , 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: 2549 Lines: 62 Hi On Wed, Apr 22, 2015 at 3:30 AM, Linus Torvalds wrote: > On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman > wrote: >> - There is a well defined translation of capability bits between user >> namespaces kdbus does not perform that translation. > > Now this looks like a big oversight, and serious. > > If you have a capability inside a lower namespace, and can fool the > other end of a kdbus connection into thinking that you have that > capability globally, then that sounds like a very obvious and bad > security issue. This needs fixing. That said, it's likely a fairly > simple fix. kdbus drops capability items if we cross user-namespaces. This security issue was fixed in v2. I think the translation Eric was referring to, is what cap_capable() (security/commoncap.c) does. That is, it translates capabilities of parent namespaces into its child namespaces (making the parent privileged in the child namespace). Right now, we don't do this. Instead, we drop the item, so the receiver knows that the information could not be gathered (unlike a zeroed capability item, which means the sender does not have the capabilities). I have an experimental patch to support translation [1]. However, I dislike copying the code from security/ into kdbus. So if we introduce translation later on, I'd like to figure out with LSM developers how to do this best. Also note that /proc does not do any translation on its own, which makes cap_get_pid() tricky to use. >> - 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. I fully agree. And to clear things up: there is no such PTRACE_MODE_READ protection for capability bits in /proc. Thanks! David [1] http://cgit.freedesktop.org/~dvdhrm/linux/commit/?h=kdbus&id=894085ff39afc653ed711102fa698d937818ce1f -- 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/