Pluggable auth modules

[Thiago Macieira]

On Friday, 3 de June de 2011 11:05:27 Bogdan Lotko wrote:
> If you already said "A" and the D-Bus specification allows TCP/IP
> connections,  then please said also "B" and maintain this branch
> properly. I think,

Ok, so you're trying to convince me to remove TCP/IP support to match my 
statement? That we can do.

Anyway, TCP/IP was provided for systems where Unix sockets don't work, like on 
Windows. There, D-Bus uses the "nonce-tcp" method. But all communication is 
confined to localhost, which is somewhat safe (as safe as processes on Windows 
can be).

> it should not be the "first" and the "second" target
> any more. All features, if already specified, shall have equal rights.
> In every D-Bus description one can read  about the possibility to
> connect over TCP/IP and realizes, that the D-Bus with its all (perfect)
> features could work like a light-weight ORB. Then learning more one
> finds out, that "actually" its not the "first and foremost" of the
> D-Bus. Its pity.

You can connect via TCP/IP, but we don't provide authentication and encryption 
and we don't want to. 

For D-Bus's main purpose, local IPC, there's no need for those. If you can 
intercept Unix-domain communications, you already have the right UID and all 
bets are lost.

For TCP/IP over localhost, to intercept the communications, you need 
privileged rights. However, since there's no UID protection, a malicious 
process running as a different user could flood the bus with packets and cause a 
denial-of-service. The nonce that Windows uses prevents accepting incoming 
connections from unauthorised users though.

For TCP/IP over an actual network, all bets are lost. Intercepting packets is 
a lot easier, since there may be any number of untrusted network devices 
reransmitting the packets between source and destination. Since the packets 
are transmitted unencrypted, any of those untrusted nodes would be able to see 
the communication. We do not want to add an encryption layer to D-Bus nor 
accept patches that do.

Without encryption, what's the point of authentication? Even if you use a non-
replayable authentication like those provided by SASL, without encryption it's 
possible to play Man-in-the-Middle attacks as well as just plain packet 
spoofing.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110603/c4a24b67/attachment.pgp>