Loadable security modules for D-Bus

[John Johansen]

On 01/09/2012 04:01 PM, Lennart Poettering wrote:
> 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.
> 
I don't see a need for this to be done as dynamically loadable modules,
but I do see a need for supporting multiple security modules. Having them
share common hook points where possible makes sense.

Specific security module support could then be configured at build time,
with which one(s) being used set by a dbus config option, or possibly
dynamically by the security modules init fn detecting whether that security
system is in use.