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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1692582

Title:
  RFE: dbus AppArmor mediation matching by message type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to