Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

On Wed, 15 Apr 2015 14:09:24 +0200 (CEST)
Jiri Kosina <jkosina@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/