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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 15 Apr 2015 13:18:28 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	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, 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.

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