Pluggable auth modules

[Daniel P. Berrange]

On Fri, Jun 03, 2011 at 02:33:31AM +0200, Lennart Poettering wrote:
> On Wed, 01.06.11 10:08, Pavel Strashkin (pavel.strashkin at gmail.com) wrote:
> 
> > Hello DBusers,
> > 
> > At the moment DBus has a few hard-coded auth mechanism and there is no
> > the way to fix them separately, extend, inherit or add a new one
> > without a patching.
> > 
> > Actually, an adding a new one is a more complicated problem because
> > you can't just add it to main repo - it must be approved by dbus team
> > or it's may be your own
> > proprietary (or for internal usage) code so the only way is keep this
> > patches under your control and merge/refresh them everytime when
> > mainstream is changed (sometimes it's difficult).
> > 
> > The idea is introduce pluggable auth modules (DLO, dynamically
> > loadable objects) via *.so/*.dll which will contain some factory
> > function to produce DBusAuthMechanismHandler instances.
> > What do you think?
> 
> Uhm. Creating our own pluggable auth iface here would be a very bad
> idea, specially since D-Bus' focus is not so much the network but local
> IPC, for which you don't need this.
> 
> I think what might be acceptable is to work on a patch that adds proper
> SASL support to D-Bus, using one of the existing
> implementations. (Cyrus, Dovecot, GNU) That way there would be no need
> to invent a new interface, but you'd have all the flexibility that SASL
> offers with its pluggable backends.

Agreed, in my experience securing VNC and libvirt, a combination of SASL +
TLS is sufficiently flexible and extensible to cover all core security
demands. Most SASL plugins only provide authentication, so you would want
to run them over a TLS encrypted session if the underlying transport isn't
secure (eg TCP). A couple of SASL plugins also provide encryption, most
notably GSSAPI w/ Kerberos, in which case they can be used to secure the
session without need for TLS too (though you may still wish to use TLS if
you want x509 certificate validation too). 

The benefit of using TLS + SASL is that both have many available impls
for apps to use, so things like the native Java DBus client can use
existing APIs to support them. SASL has many different mechanisms
available, which have a variety of security characteristics and more
importantly have been widely reviewed & thus have well understood
behaviour. I don't think DBus really wants to be providing a plugin
mechanism for people to invent custom security mechanisms, which every
DBus client has to then do a custom impl for, when it could just use
the SASL standard.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110603/5a023ca1/attachment.pgp>