Loadable security modules for D-Bus

[Lennart Poettering]

On Wed, 11.01.12 10:12, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> 
> On 11/01/12 00:16, Lennart Poettering wrote:
> >On Tue, 10.01.12 10:16, John Johansen (john.johansen at canonical.com) wrote:
> >>Splitting the packaging of D-Bus into a base
> >>package and a package for each security module to break up dependencies is
> >>more appealing than, creating separate D-Bus packages to support different
> >>security solutions.
> >
> >Yeah, I think the clear answer here is: this must be upstream. The API
> >of D-Bus is huge and baroque as it is, increasing the standardized API
> >surface even further by adding a plug-in interface would be crazy.
> 
> I agree. A purely-internal dlopen interface (in which the dlopen'd
> modules are D-Bus-version-specific, so support for SELinux, AppArmor
> and whatever else must all be built from the dbus source tarball)
> seems reasonable, but a stable API which allows out-of-tree modules
> would be a bad move. I suggest having the module directory name, or
> even the module filename, include the D-Bus version (e.g.
> ${libdir}/dbus-1.5.67/libdbus-daemon-selinux.so) to make it explicit
> that no, this is not a stable API.
> 
> Thankfully, this seems to only be needed for Linux LSMs, so we can
> simplify to "only build it on Linux, where we know dlopen() works
> sensibly" rather than having to do the same portability contortions
> as libltdl and GModule.

No, dlopen() is not an option. This should be normal code compiled into
D-Bus which is enabled/disabled at build time, and that's it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.