Re: Let's enable AppArmor by default (why not?)
On 08/10/2017 11:31 AM, Simon McVittie wrote:
> On Wed, 09 Aug 2017 at 17:17:17 -0700, John Johansen wrote:
>> The dbus code went through several revisions as well. While the dbus
>> code doesn't require a lot from the kernel, it did have some influence
>> on the kernel support interfaces.
>
> I'm curious: is the kernel side of D-Bus mediation specific to D-Bus,
> or is it general-purpose support for mediating user-space activities
> that look roughly the same shape as D-Bus?
>
The kernel side of D-Bus is generic except one flag.
It provides
- label/context info to the proc/<pid>/attr/current and SO_PEER_SEC
which are wrapped by the libapparmor api fns
- the query interface which allows user space to query policy that
is loaded into the kernel. The dbus code was the first consumer
so it helped shape what the interface looks like and how the
queries are constructed.
- a flag in the features advertising that dbus mediation support
is available. This last one currently is set by the kernel
but ideally would be enabled by the dbus code advising the
kernel module it is mediating.
For dbus mediation we assigned dbus its own class with in the
policydb. Queries to the dbus class need have the dbus query
structure, queries to other classes must follow those classes.
There is certainly some similarity between the classes, but
some of them are quite different from dbus.
Reply to: