Comment 4 for bug 1692582

> 1. the label name on a service does not have to match its executable name so an executable could be labeled with a more generic profile

Sure, but I'm not sure how this helps me to achieve what I'm aiming for, which is:

                                         privileged
    anything -------> my service ---X - > processes
                                         (systemd?)

where method calls go in the direction of the arrow, broadcast signals go in the opposite direction, and the X indicates being blocked.

If all I want is to allow my-client-app to be a client of my-service, I can already do:

    profile /usr/bin/my-service {
      ...
      dbus (send,receive) bus=session,
    }

    profile /usr/bin/my-client-app {
      ...
      dbus (send,receive) bus=session peer=(label=/usr/bin/my-service),
    }

but then my-service is also allowed to send method calls to every other session service, including systemd --user (which in practice is unconfined) - I've enabled the left hand side of the diagram above, but not blocked the right hand side.

I could also do something like

    profile foobar-service { # implemented by my-service
      ...
      dbus (send,receive) bus=session peer=(label=*_foobar-client),
    }

    profile app-123_foobar-client {
      ...
      dbus (send,receive) bus=session peer=(label=foobar-service),
    }

to restrict the profiles to being about the left hand side of my diagram, but that doesn't seem like it really scales when a particular app might be a client of lots of services.

Without distinguishing between messages by type or payload, it's also difficult to let unconfined processes use my service as clients (the platform I'm working on uses this a lot, for regression tests), without also letting my service (if it gets compromised) use unconfined services like systemd as a client. So, getting the left part but blocking the right part in this special case:

    unconfined unconfined
    utility or -------> my service ---X - > service
    automated test (systemd)

When I say "is a client of" I'm referring to the common pattern where n clients all call methods on a service and receive signals from that service, like the way GNOME Music and GNOME Documents are clients of Tracker, and Empathy and Polari are clients of Telepathy Mission Control.