There are actually a couple of ways to add it, and still keep userspace compatibility. Kernel side we are actually often checking partial matches, and due is a permission but AA_CONTINUE to indicate that if permissions aren't satisfied to continue the match.
This could be emulated in userspace a couple different ways, either by the dbus pulling the policy it needs and doing the match entirely in userspace (currently this would be the entire policy but the way things are setup this could be split out so dbus could request on the dbus relevant bits), ideally all this would just be a couple of calls into libapparmor. Or the code could use the current interface and round trip the kernel a couple of times (not ideal), though this approach becomes less and less serviceable long term).
A third approach would be to tack the type field onto the larger match string and do it as a single match.
Another approach would be to improve the kernel interfaces and update the dbus code to the improved query/matching.
All of these of course rely on the policy being able to carry some information to dbus to allow it to know if it should use the newer policy, do the extra match, what ever approach is chosen. AppArmor already has support for a key/value pair storage (its even in the upstream kernel) in policy that could be leveraged to do this.
So there are lots of options available, its a matter of choosing a design and doing the work.
There are actually a couple of ways to add it, and still keep userspace compatibility. Kernel side we are actually often checking partial matches, and due is a permission but AA_CONTINUE to indicate that if permissions aren't satisfied to continue the match.
This could be emulated in userspace a couple different ways, either by the dbus pulling the policy it needs and doing the match entirely in userspace (currently this would be the entire policy but the way things are setup this could be split out so dbus could request on the dbus relevant bits), ideally all this would just be a couple of calls into libapparmor. Or the code could use the current interface and round trip the kernel a couple of times (not ideal), though this approach becomes less and less serviceable long term).
A third approach would be to tack the type field onto the larger match string and do it as a single match.
Another approach would be to improve the kernel interfaces and update the dbus code to the improved query/matching.
All of these of course rely on the policy being able to carry some information to dbus to allow it to know if it should use the newer policy, do the extra match, what ever approach is chosen. AppArmor already has support for a key/value pair storage (its even in the upstream kernel) in policy that could be leveraged to do this.
So there are lots of options available, its a matter of choosing a design and doing the work.