Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman]

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@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.

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