Public bug reported:
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.
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
--
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
