Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753954AbbDOMTK (ORCPT ); Wed, 15 Apr 2015 08:19:10 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:43106 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753769AbbDOMS6 (ORCPT ); Wed, 15 Apr 2015 08:18:58 -0400 Date: Wed, 15 Apr 2015 13:18:28 +0100 From: One Thousand Gnomes To: Jiri Kosina Cc: Greg Kroah-Hartman , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415131828.7a66fea1@lxorguk.ukuu.org.uk> In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415120042.GF19274@kroah.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2132 Lines: 49 On Wed, 15 Apr 2015 14:09:24 +0200 (CEST) Jiri Kosina wrote: > On Wed, 15 Apr 2015, Greg Kroah-Hartman wrote: > > > 'systemctl reboot' calls a bunch of other things to determine if you > > have local access to the machine, or permissions to reboot the machine > > (i.e. CAP_SYS_BOOT), and other things that polkit might allow you to do, > > and then, it decides to reboot or not. That happens today, right? I > > don't understand the argument here. The first problem with that is that if you run the capability model in the kernel combined with our distributions through any kind of formal analysis it'll come out with more holes than a roll of wire netting. There are lots of capability handling bugs that allow you to get one capability from another where it should not be possible. Linux capabilities were a little ad-hoc and a "neat idea" in their day. It's not how anyone would do them now. At best they are ok for little things like network raw access in ping/traceroute. Thats an implementation detail. If we were to adopt something like capsicum the stuff you pass would look way different and the model would potentially work. > And what exactly is the argument that this is the way it should be > implemnted? For me the fact that capabilities are known legacy and broken, and the model will change. Better would be to just pass some "cookie" that can be used to ask "is the sender allowed to X" via the LSM modules. That futureproofs the portability I think - and is also actually more powerful anyway. > Why can't it just rely on the kernel to provide final answer to "to reboot > or not to reboot, that is the question"? It can, however you may want userspace to assert privileges and reboot even though the user doesn't have the right powers directly (think about mundane things like ctrl-alt-del or the reboot button on a desktop). Alan -- 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/