> 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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1692582
Title:
RFE: dbus AppArmor mediation matching by message type
Status in apparmor package in Ubuntu:
New
Bug description:
Suppose you're writing an AppArmor profile for a D-Bus service like
Tracker. The service might get compromised (perhaps it's network-
facing) so you don't want it to be able to act as a client of
privileged processes like systemd --user. However, imagine you do want
arbitrary third-party "apps" to be allowed to use the service if they
have appropriate rules in their own AppArmor profiles.
One reasonably natural way to encode this without tightly coupling the
service and its clients would be:
profile /usr/bin/my-service {
...
dbus send bus=session type=signal,
dbus receive bus=session type=method_call,
}
profile /usr/bin/my-client-app {
...
dbus (send,receive) bus=session peer=(label=/usr/bin/my-service),
}
However, the AppArmor integration in src:dbus and the rule parser in
src:apparmor don't allow this: they match fine-grained information
like the method name and object path, but have no concept of message
types. This seems backwards: I only expect the object path to be
useful in very rare/niche cases, but the message type is "larger" and
more important than anything else from the message payload.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
