Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754574AbbDOMal (ORCPT ); Wed, 15 Apr 2015 08:30:41 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:36878 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754372AbbDOMa2 (ORCPT ); Wed, 15 Apr 2015 08:30:28 -0400 Date: Wed, 15 Apr 2015 14:30:24 +0200 From: Greg Kroah-Hartman To: One Thousand Gnomes Cc: Jiri Kosina , 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: <20150415123024.GB20554@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415120042.GF19274@kroah.com> <20150415131828.7a66fea1@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415131828.7a66fea1@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2228 Lines: 53 On Wed, Apr 15, 2015 at 01:18:28PM +0100, One Thousand Gnomes wrote: > 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. "formal analysis"? Heh, yeah, I know all about that, and really, that's not anything we can do about here. > 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. True, the capsicum developers seem to have gone quiet on us :( > > 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. Yes, that would work, but that kind of sounds like the same thing we have today, just with a different name :) thanks, greg k-h -- 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/