Loadable security modules for D-Bus

[John Johansen]

On 01/10/2012 01:10 AM, Lennart Poettering wrote:
> On Mon, 09.01.12 17:33, John Johansen (john.johansen at canonical.com) wrote:
> 
>>>> So, yeah, not sure if I have the power to NACK this, but if I do this
>>>> gets a 1st rate NACK from me.
>>>
>>> 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.
> 
> Well, I don't know this for sure since I don't work for Suse, but afaik Suse
> more or less gave up on AppArmor, and nobody is actively maintaining it.
> 
it is maintained, still available in suse and used even

> I think most distro folks (besides Ubuntu) figured out by now that
> AppArmor is more on the crackish sides of things...
> 
> I mean, if it was for me and me alone we wouldn't bother with AppArmor
> support in D-Bus at all. But I guess we need to be fair to the Ubuntu
> folks, hence we probably need to accept patches for AppArmor.
> 
there are more security projects than just apparmor have expressed interest in
extending dbus mediation.

> If the security related code is split off into a file of its own I would
> assume that the active security architecture is dynamically checked,
> the way it is usually done for SELinux, i.e. via a call like libselinux'
> is_selinux_enabled() which is checked to enable or disable the security
> logic. Why? Because you want to handle it cleanly that people pass
> selinux=0 on the kernel cmdline, and you want the same for apparmor.
> 
sure