Loadable security modules for D-Bus

[Felipe Zimmerle]

On Jan 9, 2012, at 1:33 PM, John Johansen wrote:

> On 01/09/2012 04:45 PM, Thiago Macieira wrote:
>> 
>> I agree with Lennart and with Felipe's last paragraph: we definitely don't need 
>> dynamic loading. There is not going to be any distribution where the security 
>> mechanism isn't known at compile time.
>> 
> Well both ubuntu and suse support multiple security mechanism and would likely
> want to build support for multiple mechanisms in, having the correct mechanism
> selected when dbus is started via a config, or the security system's init code
> detecting which mechanism is in use.

Then it raise another interesting question, having the "security hooks", no matter if
dynamic loaded or not, the security implementations which will relay in those hooks
will be hosted together with D-Bus or it can be something that is maintained under its
own community? Not sure about the benefit of this, maybe it reduce the work to
maintain a code which is not D-Bus specific by the D-Bus community.

Thiago's affirmative is correct, independent of been one or more supported
frameworks, the distribution already know which security framework will be used and
can compile the code to provide the mediations for "n" supported frameworks.
However in this case, at least "n+1" runtimes dependencies will be placed. For example,
having support to SELinux depends on libselinux.so.1 and libaudit. By having support to
SElinux and AppArmor we will have three dependencies:

* libselinux.so.1 (form libselinux1 at ubuntu)
* libapparmor.so.1 (from libapparmor1 at ubuntu)
* libaudit.so.1 (from audit-libs at fedora)

And so on, for each framework that a given distribution wants to support. It means that by
installing D-Bus the user will have to have installed the libselinux and libapparmor
and also libaudit, independent of been using one, two or none LSM mediations.

Of course the distributions/os can provide various packages, like: dbus-selinux,
dbus-apparmor each of them compiled with the correct parameters and a virtual
package dbus which the dependencies can depends on. If it would be a feature of
the D-Bus daemon (e.g. Support multiple mediations) don't look the right place
to solve the problem. Anyway, like the PoC can be disabled by --disable-dsm, the
support for multiples mediation modules could be a feature that also can be
disabled or enabled in the same manner.

It is also important to note that depending on the security restrictions of a distribution,
the startup of a given mediation could be mandatory, for example, without proper
startup of the SELinux support the dbus-deamon won't start. This seems fair,
although this is only a possibility since I don't have a real use case.

Regarding the to startup the things in systemd, I have the feeling that we want to
startup the security policies/hooks/whatever before start any service, analogue of
what we have on the network: the iptables/ebtables starts before the network interfaces.

I am not saying we have to do this or that i'm just bringing the subject to the table.

Br.,
F.