Loadable security modules for D-Bus

[Lennart Poettering]

On Tue, 10.01.12 09:00, Jamie Strandboge (jamie at canonical.com) wrote:

> On Tue, 2012-01-10 at 01:10 +0100, 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.
> > 
> This is patently false. Suse still uses AppArmor and AppArmor's
> maintenance has largely been taken up by Canonical, with help from
> others. It is now in the upstream kernel and is working its way into
> Debian as well. AppArmor is active, maintained, in the upstream kernel
> and in use by various distributions.

I was referring to apparmor not being maintained by suse in suse, not
upstream. I am aware that Canonical maintains apparmor in ubuntu and
upstream.

> Also, some distributions want to provide a choice of LSMs since users
> have different requirements. For example, while AppArmor is the default
> in Ubuntu, we also have SElinux and Tomoyo available to our users. Suse
> defaults to AppArmor, but also has a choice of SElinux. Debian uses
> SElinux, but offers a choice of other LSMs (though the kernel work is
> not yet complete AFAIK). Certainly others (may want to) do the same so
> it would be nice for DBus to support this in a secure, reliable manner--
> whether it is dynamically loaded modules or some other mechanism.

Supporting doesn't just mean sticking a bit of code somewhere, it means
testing, testing and again testing. If your aim is to support everything
and that in all combinations you are exploding your test matrix without
bounds, and there's a price you have to pay for that.

But hey, I shouldn't be lecturing you on software engineering, so I'll
shut up.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.