Re: Speech Dispatcher 0.7 Beta -- Please help with testing
- From: Hynek Hanke <hanke brailcom org>
- To: trev saunders gmail com
- Cc: speechd lists freebsoft org, ubuntu-accessibility lists ubuntu com, tbsaunde main gnome org, gnome-accessibility-list gnome org, orca-list gnome org
- Subject: Re: Speech Dispatcher 0.7 Beta -- Please help with testing
- Date: Wed, 28 Apr 2010 10:06:56 +0200
There is a rather large local security problem with your use of unix sockets.
It is very easy for a local hostile user to cause a denial of service
Thanks for pointing this out. I think your concern, is valid and
we will fix it though I don't think it's one of the most important
problems for accessibility today. The situation is as follows:
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
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.
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.
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).
6) We totally support a DBus interface (it was our plan if there would
be more funding), but I think it is necessary to also have a lower level
system communication mechanism for clients like speechd-el or clients
running outside of X.
I suggest we move this now technical discussion to
speechd lists freebsoft org .
] [Thread Prev