Loadable security modules for D-Bus

[Lennart Poettering]

On Sun, 08.01.12 20:56, Felipe Zimmerle (felipe.zimmerle at collabora.co.uk) wrote:

> Hello,
> 
> Currently version of D-Bus daemon supports the mediation of messages via
> SELinux. However others linux security models are also part of the Kernel,
> they are:
> 
> * AppArmor
> * Smack
> * Tomoyo 
> 
> These security models have been adopted by some distributions (Ubuntu,
> SUSE, OpenSUSE, Mandriva) and are in use and they have already expressed
> an interest in supporting mediation of D-Bus messages, like SELinux.
> 
> Handling specific code for each implementation can increase the number of 
> dependencies and the complexity of the D-Bus daemon. Then comes the idea
> to have a simple API, enabling the creation of plugins. The idea is to
> place all LSM specific dependencies into those plugins, instead of in
> the D-Bus daemon, just the opposite of we have with the SELinux, which
> has code everywhere in the daemon.
> 
> Attached to this email there is a PoC that summarizes the idea. I am
> also making available two plugins, the first to support the AppArmor
> and the second was made in order to do the initial tests of the PoC,
> labeled dummy-dsm.
> 
> Note that the current AppArmor plugin, was an adaptation of Ubuntu
> security team experiments. It has no support for cache, and it was used
> just for tests. The AppArmor security project has plans to revise and
> update the plugin. Simple modules like the dummy module just need to
> include <dbus/dbus.h> and place a function "pre_init" to be a valid
> module.
> 
> It is not clear to me, the necessity to load the module dynamically.
> The plugin could be compiled together with D-Bus, no need for dynamic load. 
> The source can be independent, just respecting the API but built together.
> We also need to specify somehow the plugins which are mandatory to be
> loaded.

I am strongly against doing this kind of dynamic module loading in the
D-Bus daemon. Quite frankly, this is just crazy. I see no reason at all
to have dynamically loaded modules here, if this can be statically
compiled in, then I see no reason at all to create a complex module
loading infrastructure with hooks and stuff.

If you want to introduce plug-ins somewhere then you need very strong
reasons why you want to do that, and why static compilation wouldn't
suffice. Usually that also means agreeing to some kind of sane API that
plug-ins can interface with, which means major API stability concerns. I
completely don't see how the disadvantages would be outweighed by any
advantage of introducing plug-ins for security modules here. In fact I
fail to see any advantage of having a plug-in interface in the bus
daemon.

D-Bus is now one of the first daemons we start on (systemd systems at least). I
don't want such crack in such a high-profile process. (And if this
is added, then hey, I'll fork D-Bus and just stick it in systemd.)

So, yeah, not sure if I have the power to NACK this, but if I do this
gets a 1st rate NACK from me.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.