Loadable security modules for D-Bus

[Lennart Poettering]

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.

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.

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.