If I'm reading the AppArmor user-space source code correctly, if backwards compatibility wasn't a concern then this could be achieved by adding an additional user-defined field to vec in dbus_rule::gen_policy_re(Profile&) and passing the new number of fields to add_rule_vec(), then adding that same field to the queries built by dbus-daemon in bus/apparmor.c build_message_query().
Unfortunately, again if I'm reading correctly, the query works by building a long string with embedded \0 bytes, then matching it against a DFA representing a single long regular expression that also has embedded \0 bytes - if true, this would mean the number of fields can't usefully be varied. If extensibility is desired, I think the ideal thing might be if extra fields in the query were ignored (always match) and extra fields in the rule were compared as though the query had an empty string at that point in the vector, but I don't know how feasible that would be. -- 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
