Speech Dispatcher 0.7 Beta -- Please help with testing

[trev . saunders]

Hi,

> 1) Such a described DoS is as easy with the former inet socket
> implementation (any hostile user can open the port first and thus
> block it) that we have used till now. So this is actually nothing
> new.

No, it is a bit different, a server that listens on a tcp port can accept and 
handle any number of clients that connect to that port.  Unless, the server 
code is written terrible, and I confess I haven't spent much time recently 
reading that part of the code, so speechd might do something brain damaged that 
means it can only handle one connection at a time, but in principle, a server 
listening on a tcp port can handle any number of connections to the port.

> 
> 2) With session integration as done by Luke Yelavich (e.g. assigning ports
> numbers as BASE_PORT+uid), we get problems even in case of no-attack,
> since there is no guarantee that all 7560+ ports will be free to use
> and not blocked by any other service.

correct.

> 3) With ports and without authentication (former situation), in
> most current installation setups, any local user could connect to a
> session run by any other user, which was a large documented problem
> which was removed by the use of unix sockets with correct permissions.

sure, correctly done, unix sockets might be better for a session.  The way to 
protect a tcp port for  exclusive access is to use iptables.  Bill, search the 
iptables man page for user, you'll find a section that allows you to filter 
packets based on the uid of the owner of the originating socket.
 
> 4) The reason why the socket name is predictable is that clients
> could predict it and connect it without having to refer to a third
> party. If someone could suggest a good and universal (not Gnome or X based)
> mechanism so that Speech Dispatcher knows which address to run on and the
> clients know which address to connect to, without any need for some 
> pre-configuration
> (like the ever problematic SPEECHD_PORT variable), please send it to us!
> 
> 5) We might as well try to use other destination, namely ~/.speech-dispatcher
> as for all other speechd stuff (predictable but only writable by the given 
> user).

Given the current amount of thought I've put into the problem, that is what I 
would do,there might be a problem, but I haven't htought of it yet.
 
Trev