On Thu, Mar 3, 2011 at 11:02 AM, Klaus Ethgen <kl...@ethgen.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, > > Am Do den 3. Mär 2011 um 3:35 schrieb Chow Loong Jin: >> > A system has not to listen for any unused and unneeded services ever. A >> > firewall is to control services you _need_. >> > >> > All that zeroconf stuff is absolutely not needed and wanted. (By the >> > most users, I suppose.) > [...] >> Actually I absolutely love the <machine>.local resolution functionality on a >> network (it works much better than the NetBIOS crap that can never find >> another >> machine on a network when you want it). That, and Pidgin's Bonjour support >> interfaces with iChat over zeroconf, allowing you to chat with users (and >> exchange files, perhaps?) across a network without needing to set up a >> centralized chatting system. > > The thoughts of that makes me shiver! Trusting untreatable sources on a > network for configuring local stuff is worse ever. Either you have a > trustable network then it gets configured in a clean way and by intend. > Or you have a untrusted network you do not want to use ever or only such > fare that you can oversee it.
I agree and moreover because Chow Loong Jin use <machine>.local instead of <machine>.local. it could be resolved to whatever the hell to universe... >> I think those two functionalities are pretty useful to the end-user. > > Well, they might be for a mac or windows user that is not care about > security at all. But it is horror for a debian user who care at least a > bit about security. > > And even if you not care about, then that functionality should be > explicit configured and not per default. > > And even worse, debian is often used on server platforms where you never > ever want to have any such magically configured services. I agree, this sould be disable by default or at least asked to run at config time with a no default, and only be authorized to resolve if you use a fqdn and not a relative domain name... And with mdns... >> Rather than blabbering about potential security issues stemming from >> avahi-daemon being installed and enabled on a system, how about actually >> finding >> one and reporting it? > > Oh, they are not potential. Trusting on untrusted stuff for doing any on > your machine raises the vector for intrusion to hell. > > Ah, and to give a example of the past. No one ever did think about that > mssql is vulnerable due to a comfort feature until in 2001/2002 the > mssql-slammer (or how the worm was called) took down mayor parts of the > net. Zeroconf and avahi plays in the same category. > >> gnome-user-share does not share stuff by default as far as I can tell, and >> padevchooser only uses avahi-daemon for discovering extra Pulseaudio sinks on >> the network (it doesn't advertise its own sinks by default). > > Uh, you mean, that anybody can listen to your music or your teamspeak > session or your voip session with your girlfriend due zeroconf found a > audio sink in the network and did reconfigure your system to use it? > >> An avahi-enabled system that advertises no services is pretty much as secure >> as >> the avahi-disabled system. > > That is not true. For two reasons: > 1. It is one more daemon that is not needed and can have bugs. (And even > more it lowers the sensibility about unusual processes on your > system) > 2. It even configure parts of your system from untrusted information > from the network. I agree, and it is only the daemon part the depend on client part is even more scarry... We trust a lot untrusted source... > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20110303100247.ga20...@ikki.ethgen.ch > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=FVSy4PW0=t1duvgbh5fhu71kzbnfmcro64...@mail.gmail.com
