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