linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150415123024.GB20554@kroah.com>
Date:	Wed, 15 Apr 2015 14:30:24 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

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 <jkosina@...e.cz> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/