I suspect system services as snaps (ie, ones that would typically use polkit) are going to need to be considered somewhat privileged in this regard. I’m not sure how we want to expose this in terms of interfaces, but it seems reasonable that something along the lines of a snap declaration would be needed to install a polkit-using service. That said, we allow for enumeration of other snaps in various other ways, so while it would be good if we could avoid another leak, we might consider it ok (especially if it is behind a snap declaration).
Unfortunately we’ve had to allow read access of /proc/$pid/stat for some time so this is not a blocker (and underscores the difficulties in trying to confine preexisting applications that weren’t designed with confinement in mind).
I have long thought we would treat this like the udev backend (not the one for the device cgroup, but the one for installing arbitrary udev rules) in that we would have snapd interfaces that use the polkit backend, and that interface would define the polkit actions for the snap. Eg, the network-manager interface uses the new polkit backend and when a snap that slots network-manager is installed, snapd splats out the polkit files (and likely updated dbus policy files). On the surface, this seems problematic since there might be different versions of software that need different polkit actions. However, if we consider that interfaces are contracts between snaps, then I think this idea is tractable (eg, the network-manager interface supports a particular dbus API and polkit policy; if a new network-manager comes along that breaks things, we need a new interface).
I’m pretty uncomfortable with snaps providing their own policy files and this goes against the general design of other parts of the system where snapd provides the apparmor, seccomp, dbus bus policy, systemd units, session autostart, etc. We are validating the desktop files and essentially only rewriting the Exec line (and even that makes me uncomfortable), but desktop files are quite a bit different from policy files.
Beyond a security POV on getting the validation right, I worry that competing snaps providing polkit files will install different policy for the same service (eg, competing NetworkManagers; I recognize your point 2 addresses this, but bear with me). Also, since polkit has the concept of overrides via the localauthority mechanism, it would be good if this aspect was preserved with snaps such that the snap can’t simply change its polkit policy and then obviate any vendor/site/whatever changes on the system.
I suspect we are looking at this from different angles though. I’m certainly looking at this from the POV of snaps providing known core system services (eg, where a network manager snap might be used instead of a deb/rpm). I suspect you might be looking at this from the POV of “I have this arbitrary (non-core-system) service that would like to use polkit for authorization to harden its security stance”. Assuming that is your POV, I think something along the lines of what you suggested with namespaced policy, etc might be ok, but we’d want to work through some of the more problematic areas.
Perhaps these POVs are simply two different snapd concepts where both need to be implemented to support different use cases where the polkit backend approach I outlined is suitable for these system services where other snaps are meant to connect to them, having the “interface contract” honored and somewhat enforced by snapd while the polkit-interface-plus-policy approach you outlined is suitable for snaps to opt into existing technologies (ie polkit) to improve their security stance.