Re: Disable ZeroConf: how to ?
On Thu, Mar 3, 2011 at 11:02 AM, Klaus Ethgen <Klaus@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20110303100247.GA20678@ikki.ethgen.ch">http://lists.debian.org/[🔎] 20110303100247.GA20678@ikki.ethgen.ch
>
>
Reply to: