Its a different level of abstraction. Policy kit makes high level abstractions of what a program does. Like do this privileged operation. SELinux and MAC policies say this program performs these actions on these specific object in the system. These objects can be files or sockets or whatever you like. Its different concept because Policykit really doesn't map policy to system objects. It just maps it to high level concepts exposed by the mechanism. A policykit rule could be that to read my addressbook provided by some other dbus service I need to authenticate myself again. This has nothing to do with how the address book is stored on disk or any of the other resources the address book service needs to function. They are disjoint sets of permissions. Now DBUS has SELinux extensions in it. Where you can say that a process running with a certain SELinux label can contact a "mechanism" aka another service running with a different SELinux label. That's baked into DBUS however no one uses it(To the best of my knowledge). It would strengthen the use of policykit because you couldn't have arbitrary applications contact arbitrary mechanisms and requesting authorization. I guess the point that I haven't made very well in all of this is policykit isn't an access control mechanism. It more resembles an authentication mechanism and access control is still left to the underlying security mechanisms which protect the individual policykit "mechanisms". I really don't like that policy kit called their service providers mechanisms it makes the terminology confusing. Client, service provider, authentication agent make much more sense.