[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Processing (Was: [Bug-gnubg] Sound support on Mac OS X)

From: Jim Segrave
Subject: Re: Distributed Processing (Was: [Bug-gnubg] Sound support on Mac OS X)
Date: Thu, 10 Jul 2003 01:21:03 +0200
User-agent: Mutt/

On Wed 09 Jul 2003 (17:35 +0200), Olivier Baur wrote:
> (since security matters are tough issues, I've forwarded this answer to 
> the bug-gnubg list, so we can benefit from all opinions out there)
> Le mercredi, 9 juil 2003, à 16:59 Europe/Paris, Holger a écrit :
> (about using gnubg masters/slaves on the Internet)
> > One question I have, though. What about security implications? If 
> > gnubg suddenly turns out to be a server that other people can connect 
> > to...  Does it accept any (recognized) command? If not there might 
> > still be buffer overruns or the like. Could this be an issue?
> Yes, security is always a big issue.
> There are no gnubg commands exchanged (so no risk for commands like 
> "!do-something-very-bad"); the session protocol is just about task 
> requests being sent from master to slave and results being sent back 
> from slave to master (as bunches of gnubg structs in binary format).
> However, even without talking about buffer overrun bugs (like what 
> happened on MS Windows http servers), there are some concerns about 
> people setting up fake gnubg slaves that could send back corrupted 
> results to masters (either corrupting net results or crashing the 
> masters,) or overflow masters with notifications, or whatever.
> Please note that slaves don't connect to masters; a master will connect 
> to a slave when instructed by its user; so the only risk is for masters 
> that listen to all availability notifications they receive from the 
> Internet -- these guys could connect to someone who's not the good 
> helping slave he pretends to be...
> I've already been thinking about some security locks; for example, 
> masters could set up a list of authorized slaves, based either on IP 
> address or username/password authorization. There is also an IP-mask 
> filter feature, to restrict masters to listening only to a specific IP 
> sub-network; this is not yet implemented in the GTK interface, but can 
> be set up using "set pu remote mask <ip-mask>".

If the port numbers on the server side are well defined, consider
linking with libwrap - that gives excellent control over what machines
can and can not connect based on IP address. If you want to add user
level authentication and security, consider running the connection via
an ssh tunnel - the programs bind only to localhost, a local client
then connect via an ssh tunnel.

The advantages are that you are now using security systems which are
widely deployed, well understood, and updated regularly if any flaws
are found. 

tcp-wrappers is very effective for IP address level authentication,
don't try to invent your own.

ssh tunnelling is probebaly the most secure method you will find for
remote network connections between multi-user machines.

Jim Segrave           address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]