Disable ZeroConf: how to ?
Bastien ROUCARIES
More and more packages depend on avahi aka zeroconf. I have found some information on http://wiki.debian.org/ZeroConf
Because I work in a untrusted work place and home network (public networks, wifi...) I whish to purge zeroconf functionnality.
however a lot of package depends (or recommend) instead of suggest avahi-daemon and thus I could not purge this piece of software
that I believe insecure in my context.
Does avahi could be disable (using kernel level firewalling is not from my point of view a solution) ?
And more specifically from an administrator point of view does avahi could library could be made purgeable and no more than suggest
dependencies (I am willing to fill a mass bug report because purging avahi will purge gnome and kde ...) ?
And moreover could you give a clear answer about the security risk on untrusted network ?
Thanks
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201103021825.32204...@gmail.com
Philipp Kern
I won't comment on the possible insecurity of avahi-daemon, but...
On 2011-03-02, Bastien ROUCARIES <roucarie...@gmail.com> wrote:
> More and more packages depend on avahi aka zeroconf. I have found some
> information on http://wiki.debian.org/ZeroConf
>
> Because I work in a untrusted work place and home network (public networks,
> wifi...) I whish to purge zeroconf functionnality.
>
> however a lot of package depends (or recommend) instead of suggest
> avahi-daemon and thus I could not purge this piece of software
> that I believe insecure in my context.
| pkern@franck:~$ dak rm -n -R -b -s stable avahi-daemon
| Working... done.
| Will remove the following packages from stable:
|
| avahi-daemon | 0.6.27-2 | amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
|
| Maintainer: Utopia Maintenance Team <pkg-utopia-...@lists.alioth.debian.org>
|
| ------------------- Reason -------------------
|
| ----------------------------------------------
|
| Checking reverse dependencies...
| # Broken Depends:
| avahi: avahi-discover
| avahi-dnsconfd
| avahi-utils
| controlaula: ltsp-controlaula
| forked-daapd: forked-daapd
| gshare: gshare
| mandos: mandos
| meta-gnome2: gnome
| mod-dnssd: libapache2-mod-dnssd
| mt-daapd: mt-daapd
| nss-mdns: lib32nss-mdns [amd64]
| libnss-mdns
| padevchooser: padevchooser
| service-discovery-applet: service-discovery-applet
| telepathy-salut: telepathy-salut
|
| Dependency problem found.
So it's mainly gnome, which you don't need to install if you don't agree with
the maintainer's decision to depend on avahi-daemon, but you could mark the
pulled-in packages as installed yourself. (That's the maintainer's stance on
its dependency list.)
The other thing where it's not clear to me is padevchooser. Not sure it's
really desperatly needed there.
But the "a lot of packages depend" on it is false. It might be true that a
bunch of it recommend it, but then you could create a dummy package that just
conflicts against avahi-daemon. That should keep it uninstalled even when you
install more packages with recommends turned on. (I think equivs could help
you there.) After all those are no depends.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnimtckc...@kelgar.0x539.de
Josselin Mouette
> And more specifically from an administrator point of view does avahi
> could library could be made purgeable and no more than suggest
> dependencies (I am willing to fill a mass bug report because purging
> avahi will purge gnome and kde ...) ?
As Philipp pointed out, only gnome depends on it, and that’s not
gnome-desktop-environment. You can use the latter if you want only the
official GNOME desktop.
> And moreover could you give a clear answer about the security risk on
> untrusted network ?
I’d say Avahi is mostly as insecure as the services that use it for
advertising.
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
Steve Langasek
> The other thing where it's not clear to me is padevchooser. Not sure it's
> really desperatly needed there.
For padevchooser it probably makes sense, as network sound sink/sources are
certainly a case you may want to use pulseaudio with.
What I find unusual is that pulseaudio recommends padevchooser. I wouldn't
expect this to be installed by default.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Julien BLACHE
Hi,
> Because I work in a untrusted work place and home network (public
> networks, wifi...) I whish to purge zeroconf functionnality.
Looks like you want a firewall. Just sayin'.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87pqq9k...@sonic.technologeek.org
Klaus Ethgen
Hash: SHA512
Am Mi den 2. Mär 2011 um 23:09 schrieb Julien BLACHE:
> > Because I work in a untrusted work place and home network (public
> > networks, wifi...) I whish to purge zeroconf functionnality.
>
> Looks like you want a firewall. Just sayin'.
Ehem, no.
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.)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTW7LKp+OKpjRpO3lAQpkRgf/VKrQKWxC83u3XbGK8/Q1AaHvfa4zweUj
wWyGHQjs98OLxdqfONq/7v1eHzGbFghgBzPXiEIdVBDgnCPnSU+QTNRYvUyx8O58
iSdO0GMERDnMg1nU0tunTG4NgmXfoysJttpE4zPiyy51nhUNfbe9giQmMpZ94tIb
GGTF49YUiAZde1uUk6NDXEjXlsBtoeID2WiNKnwTrQbXGBLD7fgdfeSGoEzCvkNq
9YCF/cHTQbV1x0q1RFUcbbAbd6eCin2mmhX92iIhX15KgNdaE1sZ6bCMUJAh0Rhr
Ab9jGki0AxfV4N6Y43CztskNa+EHhmKhe/mkk5NilVZ7IovJ+CXWJQ==
=Wxv3
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110302225...@ikki.ethgen.ch
Ben Hutchings
> Bastien ROUCARIES <roucarie...@gmail.com> wrote:
>
> Hi,
>
> > Because I work in a untrusted work place and home network (public
> > networks, wifi...) I whish to purge zeroconf functionnality.
>
> Looks like you want a firewall. Just sayin'.
A firewall is mitigation against insecure applications and
configurations. The availability of firewalls does not excuse us from
making applications and their default configurations secure.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Klaus Ethgen
Hash: SHA512
Am Mi den 2. Mär 2011 um 18:25 schrieb Bastien ROUCARIES:
> More and more packages depend on avahi aka zeroconf. I have found some information on http://wiki.debian.org/ZeroConf
>
> Because I work in a untrusted work place and home network (public networks, wifi...) I whish to purge zeroconf functionnality.
I fighted this bunch of functionality since long ago. The whole zerconf
stuff is only useful in secure and clear defined environments. But there
you don't need it anyway.
With zeroconf there is some thinks that play together and has to be
killed:
- - avahi (-daemon) -- as you find by yourself -- and the packages
zeroconf, libnss-mdns, avahi-autoipd, avahi-daemon.
- - The package slpd
- - The linklocal route (169.254.0.0)
> Does avahi could be disable (using kernel level firewalling is not from my point of view a solution) ?
See above.
> And more specifically from an administrator point of view does avahi could library could be made purgeable and no more than suggest
> dependencies (I am willing to fill a mass bug report because purging avahi will purge gnome and kde ...) ?
Well, as I do not use gnome nor kde I am not concerned from this
dependencies.
> And moreover could you give a clear answer about the security risk on untrusted network ?
That is difficult. It depends on the environment. If you have a clear
and secure environment, zeroconf is not that insecure. But in all other
environments you do not want to have it.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTW7Knp+OKpjRpO3lAQqjdgf+J1Tq4eqF+bi/2bAONvCPXgwCXRswg5eA
HEAWZdsN13jTe/JGD/NTBML7AXXu+RIeJIFty+I/T+OlU2x3SbKijtXkteN0giTE
QWJf/6extnJZY97+cP2xDjfPZXP8DA7pL3qr0MLHj9Lz/s+Prvd+9MM3OKzgoDn/
pG9Lb+TVNMzWmD3KLGD1wbLMMKSnh7NLQshQPLgwkZwTysLWCeIX/hBRZ8r9Nn0G
DqW1I4sOIYB47w4DmHo5SXwnQG3O0P/MdbaVicasE0+MYLg28Ib+ZVNMzvFbP7Kw
lBQBvrqFDBsKXvK4esgSlI6xq8c/m/rUUR5S3Ar8t8AFg1OWoT+C4g==
=CXGk
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110302225...@ikki.ethgen.ch
Adam Borowski
> Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
> > And more specifically from an administrator point of view does avahi
> > could library could be made purgeable and no more than suggest
> > dependencies (I am willing to fill a mass bug report because purging
> > avahi will purge gnome and kde ...) ?
>
> As Philipp pointed out, only gnome depends on it, and that’s not
> gnome-desktop-environment. You can use the latter if you want only the
> official GNOME desktop.
gnome-desktop-environment
Depends: gnome-user-share
Depends: libapache2-mod-dnssd
Depends: avahi-daemon
Recommends: telepathy-salut
Depends: avahi-daemon
> > And moreover could you give a clear answer about the security risk on
> > untrusted network ?
>
> I’d say Avahi is mostly as insecure as the services that use it for
> advertising.
A client system is not supposed to run any public network services,
especially not in the default config. I have never in my life felt the need
to do anything provided by either gnome-user-share or telepathy-salut (or
anything that has to do with telepathy for that matter), and I doubt most
users have either. None of them do anything good unless configured, too.
Having them installed by default might make sense, disk space is cheap and
non-technical users are not supposed to apt-get things every time they use
an optional part of Gnome -- but why the system would bear a security risk
when none of the programs involved were ever run is beyond me.
When an user actually uses that "easy file sharing" or link-local instant
messaging, avahi could be started, but there's no reason to do that before.
This goes in contrast to actual server daemons which are installed by a
conscious action by the sysadmin, and thus can be expected to be running by
default.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chow Loong Jin
> Am Mi den 2. Mär 2011 um 23:09 schrieb Julien BLACHE:
>>> Because I work in a untrusted work place and home network (public
>>> networks, wifi...) I whish to purge zeroconf functionnality.
>
>> Looks like you want a firewall. Just sayin'.
>
> Ehem, no.
>
> 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.)
>
> Regards
> Klaus
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.
I think those two functionalities are pretty useful to the end-user.
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?
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).
An avahi-enabled system that advertises no services is pretty much as secure as
the avahi-disabled system.
--
Kind regards,
Loong Jin
Norbert Preining
> On Wed, Mar 02, 2011 at 10:24:36PM +0100, Josselin Mouette wrote:
> > As Philipp pointed out, only gnome depends on it, and that’s not
> > gnome-desktop-environment. You can use the latter if you want only the
> > official GNOME desktop.
>
> gnome-desktop-environment
> Depends: gnome-user-share
> Depends: libapache2-mod-dnssd
> Depends: avahi-daemon
> Recommends: telepathy-salut
> Depends: avahi-daemon
Any words of the GNOME maintainers according to that?
I don't need not want avahi, it actually two or three times broke
my network by doing changes to config file I don't want (don't remember
the details) and at that time I could purge it away, but it came back
again.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
HIGH OFFLEY (n.)
Gossnargh (q.v.) three weeks later.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011030303...@gamma.logic.tuwien.ac.at
Gerfried Fuchs
* Bastien ROUCARIES <roucarie...@gmail.com> [2011-03-02 18:25:30 CET]:
> Does avahi could be disable (using kernel level firewalling is not
> from my point of view a solution) ?
A nice hack that I was informed just recently about:
echo exit 0 >> /etc/default/avahi-daemon
That will disable the daemon quite effectively.
Rhonda
--
"What are the differences between Mark Zuckerberg and me? I give private
information on corporations to you for free, and I'm a villain.
Zuckerberg gives your private information to corporations for money and
he's Man of the Year." -- Julian Assange
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303081...@anguilla.debian.or.at
Bastien ROUCARIES
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Mi den 2. Mär 2011 um 18:25 schrieb Bastien ROUCARIES:
>> More and more packages depend on avahi aka zeroconf. I have found some information on http://wiki.debian.org/ZeroConf
>>
>> Because I work in a untrusted work place and home network (public networks, wifi...) I whish to purge zeroconf functionnality.
>
> I fighted this bunch of functionality since long ago. The whole zerconf
> stuff is only useful in secure and clear defined environments. But there
> you don't need it anyway.
>
> With zeroconf there is some thinks that play together and has to be
> killed:
> - - avahi (-daemon) -- as you find by yourself -- and the packages
> zeroconf, libnss-mdns, avahi-autoipd, avahi-daemon.
> - - The package slpd
> - - The linklocal route (169.254.0.0)
Ok so this package should be marked as suggest only ? Will fill bug,
if needed as a whislist level.
>> Does avahi could be disable (using kernel level firewalling is not from my point of view a solution) ?
>
> See above.
>
>> And more specifically from an administrator point of view does avahi could library could be made purgeable and no more than suggest
>> dependencies (I am willing to fill a mass bug report because purging avahi will purge gnome and kde ...) ?
>
> Well, as I do not use gnome nor kde I am not concerned from this
> dependencies.
>
>> And moreover could you give a clear answer about the security risk on untrusted network ?
>
> That is difficult. It depends on the environment. If you have a clear
> and secure environment, zeroconf is not that insecure. But in all other
> environments you do not want to have it.
Ok so a telnet equivalent from a security point of view...
Regards
Bastien
> Regards
> Klaus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimVgZuWM-btAmjJe...@mail.gmail.com
Bastien ROUCARIES
> On Wed, 2011-03-02 at 23:09 +0100, Julien BLACHE wrote:
>> Bastien ROUCARIES <roucarie...@gmail.com> wrote:
>>
>> Hi,
>>
>> > Because I work in a untrusted work place and home network (public
>> > networks, wifi...) I whish to purge zeroconf functionnality.
>>
>> Looks like you want a firewall. Just sayin'.
>
> A firewall is mitigation against insecure applications and
> configurations. The availability of firewalls does not excuse us from
> making applications and their default configurations secure.
I perfectly agree...
Bastien
> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTicR_5giGbqxkOyNp...@mail.gmail.com
Klaus Ethgen
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 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.
> 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.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTW9nR5+OKpjRpO3lAQrpqgf/UD6Vmg5rF/RhVY9VPgPpx3FdcFQXJ3b0
IJsdsPL+7MsUEblqTlabxuDPALXM/RcORDQaTX+2wzeaLO5Tu9+ZoeuvNiT9mNWy
NLoqFWIRtoDYiwlQK2KfCT0PGLU9EEa1ynk3naIhVp/QPods2bpHG3lIYMgPCY4D
A0Y+6knrWjwRLVRiWQuzRhH6T6ykbPkw08yr1/9vy45CiRXbXvIpk9vJhpOPD7nX
sxfY2bMIk5NCUKdJ6QVLKUe+HM5wJO0IsRSMNPFg+RLk99xEYUgP87MeUi7O14CC
9VfopJAak/MYttLLxW6K0X/Ltoflpqr58TWvmzDpIS0VSBEA3wkwoA==
=okFJ
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303100...@ikki.ethgen.ch
Bastien ROUCARIES
> Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
>> And more specifically from an administrator point of view does avahi
>> could library could be made purgeable and no more than suggest
>> dependencies (I am willing to fill a mass bug report because purging
>> avahi will purge gnome and kde ...) ?
>
> As Philipp pointed out, only gnome depends on it, and that’s not
> gnome-desktop-environment. You can use the latter if you want only the
> official GNOME desktop.
Not true anymore see below:
gnome-desktop-environment
Depends: gnome-user-share
Depends: libapache2-mod-dnssd
Depends: avahi-daemon
Recommends: telepathy-salut
Depends: avahi-daemon
>> And moreover could you give a clear answer about the security risk on
>> untrusted network ?
>
> I’d say Avahi is mostly as insecure as the services that use it for
> advertising.
Yes I have just read the draft RFC and it document some pitfall in
insecure network:
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
In an environment where the participants are mutually antagonistic
and unwilling to cooperate, other mechanisms are appropriate, like
manually administered DNS.
In an environment where there is a group of cooperating participants,
but there may be other antagonistic participants on the same physical
link, the cooperating participants need to use IPSEC signatures
and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
messages from trusted participants (which they process as usual) from
mDNS messages from untrusted participants (which they silently
discard).
When DNS queries for *global* DNS names are sent to the mDNS
multicast address (during network outages which disrupt communication
with the greater Internet) it is *especially* important to use
DNSSEC, because the user may have the impression that he or she is
communicating with some authentic host, when in fact he or she is
really communicating with some local host that is merely masquerading
as that name. This is less critical for names ending with ".local.",
because the user should be aware that those names have only local
significance and no global authority is implied.
Most computer users neglect to type the trailing dot at the end of a
fully qualified domain name, making it a relative domain name (e.g.
"www.example.com"). In the event of network outage, attempts to
positively resolve the name as entered will fail, resulting in
application of the search list, including ".local.", if present.
A malicious host could masquerade as "www.example.com." by answering
the resulting Multicast DNS query for "www.example.com.local."
To avoid this, a host MUST NOT append the search suffix
".local.", if present, to any relative (partially qualified)
host name containing two or more labels. Appending ".local." to
single-label relative host names is acceptable, since the user
should have no expectation that a single-label host name will
resolve as-is.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinaxgo2-sd9FsnqH...@mail.gmail.com
Tollef Fog Heen
Hi,
| The thoughts of that makes me shiver! Trusting untreatable sources on a
| network for configuring local stuff is worse ever.
Then just don't use it? Nobody is forcing you to.
| > 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.
That makes it much less useful. On the other hand, it's not like your
system will suddenly go around connecting to random services just
because it sees them announced.
| And even worse, debian is often used on server platforms where you never
| ever want to have any such magically configured services.
Oh, I quite like services to announce themselves so I can just do ssh
foo.local. Not everything gets set up in DNS and ssh caches the host
key so doing a mitm attack after the initial handshake is prevented.
It's not like it'll magically be pulled in on servers or anybody is
suggesting making it part of the base system.
| 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.
Except zeroconf isn't routed so to be able to exploit it you need to be
on the same physical segment?
| > 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?
That they are discovered does not mean they are used, just that they are
available. If you have found any bugs where network sinks are used
automatically please file bugs about that.
Really, if you want to disable avahi, please feel free to do so on your
systems. Or use a firewall, or both. Debian has a fair balance of
functionality, security and convenience out of the box, if you disagree
with the current balance, feel free to invest the work into making it
possible to harden Debian further.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87sjv4j...@qurzaw.varnish-software.com
Bastien ROUCARIES
> -----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-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/20110303100...@ikki.ethgen.ch
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTiFVSy4PW0T1DUVG...@mail.gmail.com
Bastien ROUCARIES
> ]] Klaus Ethgen
>
> Hi,
>
> | The thoughts of that makes me shiver! Trusting untreatable sources on a
> | network for configuring local stuff is worse ever.
>
> Then just don't use it? Nobody is forcing you to.
>
> | > 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.
>
> That makes it much less useful. On the other hand, it's not like your
> system will suddenly go around connecting to random services just
> because it sees them announced.
>
> | And even worse, debian is often used on server platforms where you never
> | ever want to have any such magically configured services.
>
> Oh, I quite like services to announce themselves so I can just do ssh
> foo.local.
The balance about using FQDN like you do and not foo.local that will
resolve to hell
> Not everything gets set up in DNS and ssh caches the host
> key so doing a mitm attack after the initial handshake is prevented.
> It's not like it'll magically be pulled in on servers or anybody is
> suggesting making it part of the base system.
It is pulled when I use gnome on my server...
> | 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.
>
> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?
>
> | > 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?
>
> That they are discovered does not mean they are used, just that they are
> available. If you have found any bugs where network sinks are used
> automatically please file bugs about that.
>
> Really, if you want to disable avahi, please feel free to do so on your
> systems. Or use a firewall, or both. Debian has a fair balance of
> functionality, security and convenience out of the box, if you disagree
> with the current balance, feel free to invest the work into making it
> possible to harden Debian further.
But how to disable was not documented and that is the problem...
Moreover current configuration that allow to use local link that are
not FQDN is a little bit insecure
Bastien
> Regards,
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/87sjv4j...@qurzaw.varnish-software.com
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinfcvL7j6s-KLNM...@mail.gmail.com
Klaus Ethgen
Hash: SHA512
Hi,
Am Do den 3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
> Then just don't use it? Nobody is forcing you to.
[...]
> | And even if you not care about, then that functionality should be
> | explicit configured and not per default.
>
> That makes it much less useful. On the other hand, it's not like your
> system will suddenly go around connecting to random services just
> because it sees them announced.
So you contradict yourself within two paragraphs. It makes it less
useful to enable it only on manual intervention (say, it should be
enabled automatic) but on the other hand you say that nobody is forcing
me (or others) to use it. How do that plays together?
> Oh, I quite like services to announce themselves so I can just do ssh
> foo.local. Not everything gets set up in DNS and ssh caches the host
> key so doing a mitm attack after the initial handshake is prevented.
Not ever service has that security fence.
> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?
Physical might be relative with wireless networks. But you are true,
that isn't routed (good thanks), but that hinders it only from taking
down the whole net.
> If you have found any bugs where network sinks are used automatically
> please file bugs about that.
Oh, there is no change of that as I never ever will use such stuff.
> Really, if you want to disable avahi, please feel free to do so on your
> systems.
That the discussion is about, yes. And the pressure some dependencies
bring in.
> Or use a firewall, or both.
It is told on other places that firewalling is not the solution.
> Debian has a fair balance of functionality, security and convenience
> out of the box,
Unfortunately some people on debian started to place convenience much
higher as security. I think that is a dangerous trend. Debian gives up
more and more security for convenience.
> if you disagree with the current balance, feel free to invest the work
> into making it possible to harden Debian further.
Oh, I did. I am not a DD and involved myself in some discussions about
that. But finally I found out that the force of (some) DDs is higher
than mine and that they misuse it. So I am only able to fix that issues
I have locally and share the hardened packages to others on a private
repository. That is not great but sometimes it is the only workable way.
And it is no easy way.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTW9zVZ+OKpjRpO3lAQrwpAf+Nr0JUdpUpSeyyFKSRXGEbsxibvBbORWm
j6DYb4QhwftUx75Kj/7dVQtu9MrGYzykHjUxTPyM00jRfjSOgcCzMdFPt3NXEWtG
WeCXFrtsFW+1ulQQY+3p9QSGlR1PwduEhWKrhIDMwbatLdFHCl/JoQk2dRj2Tkza
33HHca1zrfeCslqbeemrsKSDo0m3WT94futvFNwpJGVBgDBhRuhBHqvgEC3HNrJj
HmdYE14nnAI4qPjRkPYe4lRFI6A1geET30ToHfY/xVOS6FuvTlJmWI/U1CDr/6YI
71OE65YEl1UzJu5U2LpcubkG1sHrdl3kNAJobNuABQPJRStPROA/Lg==
=nivA
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303105...@ikki.ethgen.ch
Mike Hommey
> > Not everything gets set up in DNS and ssh caches the host
> > key so doing a mitm attack after the initial handshake is prevented.
> > It's not like it'll magically be pulled in on servers or anybody is
> > suggesting making it part of the base system.
>
> It is pulled when I use gnome on my server...
Isn't using gnome on a server asking for trouble already ?
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Julien BLACHE
Hi,
> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?
mDNS traffic can actually be relayed, but this requires setting up a
relay daemon on the gateway(s).
Quite useful when done properly.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87pqq8b...@sonic.technologeek.org
Lars Wirzenius
> Am Do den 3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
> > Then just don't use it? Nobody is forcing you to.
> [...]
> > | And even if you not care about, then that functionality should be
> > | explicit configured and not per default.
> >
> > That makes it much less useful. On the other hand, it's not like your
> > system will suddenly go around connecting to random services just
> > because it sees them announced.
>
> So you contradict yourself within two paragraphs. It makes it less
> useful to enable it only on manual intervention (say, it should be
> enabled automatic) but on the other hand you say that nobody is forcing
> me (or others) to use it. How do that plays together?
I don't see a contradiction between "nobody is forced to use zeroconf"
and "zeroconf is less useful if it has to be enabled manually". The fact
that zeroconf is enabled by default on the GNOME desktop does not make
it mandatory for everyone to use. (Yes, it would be nice if there were
an easy way to disable it.)
However, could we please end the FUDfest? This thread seems to be quite
unconstructive, with unspecific claims of security problems, unwarranted
slurs on users based on their operating system, and accusations on
Debian developer's attitudes. If there is an actual problem, explain
what it is, and suggest a solution. Be specific. Avoid hyperbole and
vague generalities. Do not insult. Write few mails, but put effort into
each one. If others don't agree with you, possibly you are unclear and
they are not stupid or evil: rephrase and expand and ask questions, and
don't get frustrated.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299151335.2561.17.camel@tacticus
Sujit Karatparambil
> unconstructive, with unspecific claims of security problems, unwarranted
> slurs on users based on their operating system, and accusations on
> Debian developer's attitudes. If there is an actual problem, explain
I totally agree, it is certainly not wise to accuse/allege/propgate fud.
I also think it is much better to look for articles on the internet that
might help you better understand. As with opensource it is very difficult
to maintain a document for a long period of time. But certainly usefull
as pointer to usefull information into the manpages. Though I am not an
expert of ZeroConf but found a usefull article into zeroconf. I am much more
an Avahi fan than an ZeroConf fan.
http://www.practicallynetworked.com/sharing/configure_and_use_avahi_and_linux.htm
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTikC2z4-3c9QhBVDY...@mail.gmail.com
Bastien ROUCARIES
<sujit.k...@gmail.com> wrote:
>> However, could we please end the FUDfest? This thread seems to be quite
>> unconstructive, with unspecific claims of security problems, unwarranted
>> slurs on users based on their operating system, and accusations on
>> Debian developer's attitudes. If there is an actual problem, explain
>
> I totally agree, it is certainly not wise to accuse/allege/propgate fud.
> I also think it is much better to look for articles on the internet that
> might help you better understand. As with opensource it is very difficult
> to maintain a document for a long period of time. But certainly usefull
> as pointer to usefull information into the manpages. Though I am not an
> expert of ZeroConf but found a usefull article into zeroconf. I am much more
> an Avahi fan than an ZeroConf fan.
>
> http://www.practicallynetworked.com/sharing/configure_and_use_avahi_and_linux.htm
some package announce their existance to the world without any admin decision!
It is not a fud and a security hole!
>phpmyadmin package have created a link in /etc/avahi/services without
>any question. Everybody know in my network that I have a phpadmin
>service running on my server. I will ASAP create a bug report with a
> security tag.
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinkQ=Q8wX45zbODT7WqUwX...@mail.gmail.com
Bastien ROUCARIES
> On to, 2011-03-03 at 11:54 +0100, Klaus Ethgen wrote:
>> Am Do den 3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
>> > Then just don't use it? Nobody is forcing you to.
>> [...]
>> > | And even if you not care about, then that functionality should be
>> > | explicit configured and not per default.
>> >
>> > That makes it much less useful. On the other hand, it's not like your
>> > system will suddenly go around connecting to random services just
>> > because it sees them announced.
>>
>> So you contradict yourself within two paragraphs. It makes it less
>> useful to enable it only on manual intervention (say, it should be
>> enabled automatic) but on the other hand you say that nobody is forcing
>> me (or others) to use it. How do that plays together?
>
> I don't see a contradiction between "nobody is forced to use zeroconf"
> and "zeroconf is less useful if it has to be enabled manually". The fact
> that zeroconf is enabled by default on the GNOME desktop does not make
> it mandatory for everyone to use. (Yes, it would be nice if there were
> an easy way to disable it.)
>
> However, could we please end the FUDfest? This thread seems to be quite
> unconstructive, with unspecific claims of security problems, unwarranted
> slurs on users based on their operating system, and accusations on
> Debian developer's attitudes. If there is an actual problem, explain
> what it is, and suggest a solution.
main security problem is resolver,
$host -v www.local
www.local
www.local.mydomain.com
see security issue in draft paper also in case
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
more important:
phpmyadmin package have created a link in /etc/avahi/services without
any question. Everybody know in my network that I have a phpadmin
service running on my server. I will ASAP create a bug report with a
security tag.
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTikeZVy0EtUVdfw0M...@mail.gmail.com
Lars Wirzenius
> some package announce their existance to the world without any admin decision!
> It is not a fud and a security hole!
That's a vague generality... which packages? You mentioned phpmyadmin.
What are the actual problems that results from this announcement? What
bad things happen from it? Can the fact that you have phpmyadmin become
known to an attacker via port scanning, or similar techniques? If so,
does it matter if phpmyadmin also announces things via avahi? What do
you suggest as a solution? Would a blanket policy of having all services
to default to not announce themselves? What would the problems from such
a policy be?
(I don't know much about this stuff, and I don't particularly care, but
it'd be nice if we could turn the discussion into a constructive one.)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299154617.2561.23.camel@tacticus
Olaf van der Spek
> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>> some package announce their existance to the world without any admin decision!
>> It is not a fud and a security hole!
>
> That's a vague generality... which packages? You mentioned phpmyadmin.
> What are the actual problems that results from this announcement? What
> bad things happen from it? Can the fact that you have phpmyadmin become
> known to an attacker via port scanning, or similar techniques? If so,
> does it matter if phpmyadmin also announces things via avahi? What do
> you suggest as a solution? Would a blanket policy of having all services
> to default to not announce themselves? What would the problems from such
> a policy be?
>
> (I don't know much about this stuff, and I don't particularly care, but
> it'd be nice if we could turn the discussion into a constructive one.)
Windows has the concept of home / private and public networks. On
public networks, sharing gets disabled.
Such a concept would be good for this situation as well. Let the user
indicate what type of network he is on and what type of services
should be opened to that network.
Olaf
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinTbSLqb6ErtkOAB...@mail.gmail.com
Bastien ROUCARIES
> On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius <l...@liw.fi> wrote:
>> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>>> some package announce their existance to the world without any admin decision!
>>> It is not a fud and a security hole!
>>
>> That's a vague generality... which packages? You mentioned phpmyadmin.
>> What are the actual problems that results from this announcement? What
>> bad things happen from it? Can the fact that you have phpmyadmin become
>> known to an attacker via port scanning, or similar techniques? If so,
>> does it matter if phpmyadmin also announces things via avahi? What do
>> you suggest as a solution? Would a blanket policy of having all services
>> to default to not announce themselves? What would the problems from such
>> a policy be?
>>
>> (I don't know much about this stuff, and I don't particularly care, but
>> it'd be nice if we could turn the discussion into a constructive one.)
>
> Windows has the concept of home / private and public networks. On
> public networks, sharing gets disabled.
> Such a concept would be good for this situation as well. Let the user
> indicate what type of network he is on and what type of services
> should be opened to that network.
The last bug is not about this, it is I have a phpmyadmin running as
www user and I announce I run it.
Not really good to give the path to phpmyadmin (that is running by
admin decission)
Bastien
> Olaf
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/AANLkTinTbSLqb6ErtkOAB...@mail.gmail.com
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimNDs4CcgJvYxqr_...@mail.gmail.com
Mike Hommey
Zeroconf announce doesn't make it less secure, it makes it slightly more
discoverable, but not significantly so.
Conversely, believing that not announcing through zeroconf is more
secure is probably good for your self confidence but doesn't change
anything about actual security of your system.
Script kiddies will actually scan a network, find web servers, and
test a bunch of urls, in which the default phpmyadmin path most
probably appears.
And if your phpmyadmin is exploited, it won't be because of zeroconf,
it will be because of your weak password, of a security issue in
phpmyadmin, or something else.
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303133...@glandium.org
Bastien ROUCARIES
I disagree, on the second part, I allow faster discovery of attack
target, and made script kiddies less detectable...
> Conversely, believing that not announcing through zeroconf is more
> secure is probably good for your self confidence but doesn't change
> anything about actual security of your system.
It will ease the work of script kiddy.
> Script kiddies will actually scan a network, find web servers, and
> test a bunch of urls, in which the default phpmyadmin path most
> probably appears.
>
> And if your phpmyadmin is exploited, it won't be because of zeroconf,
> it will be because of your weak password, of a security issue in
> phpmyadmin, or something else.
For sure but I really dislike to help script kiddies, we do not return
full version of some software for this reason and do not announce
software available and location of administrative stuff slow down
exploit
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimAnzrPnEgioQECc...@mail.gmail.com
Josselin Mouette
> > As Philipp pointed out, only gnome depends on it, and that’s not
> > gnome-desktop-environment. You can use the latter if you want only the
> > official GNOME desktop.
>
> gnome-desktop-environment
> Depends: gnome-user-share
Ah right, this one was added more recently.
> A client system is not supposed to run any public network services,
> especially not in the default config. I have never in my life felt the need
> to do anything provided by either gnome-user-share or telepathy-salut (or
> anything that has to do with telepathy for that matter), and I doubt most
> users have either. None of them do anything good unless configured, too.
Note that until you configure gnome-user-share, only avahi is started;
gnome-user-share itself is not.
> When an user actually uses that "easy file sharing" or link-local instant
> messaging, avahi could be started, but there's no reason to do that before.
That might be possible using D-Bus activation. Feel free to get in touch
with the avahi developers if you want to implement it.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299161834.26821.92.camel@meh
Simon McVittie
> > I have never in my life felt the need
> > to do anything provided by either gnome-user-share or telepathy-salut
>
> gnome-user-share itself is not.
The same for telepathy-salut, FWIW. (If Empathy starts up without any IM
accounts, it'll offer to make you a link-local IM account using Salut, but you
can always say no.)
> > When an user actually uses that "easy file sharing" or link-local instant
> > messaging, avahi could be started, but there's no reason to do that before.
>
> That might be possible using D-Bus activation. Feel free to get in touch
> with the avahi developers if you want to implement it.
Avahi also needs to be running to consume services advertised with zeroconf,
so if you use anything that browses for advertised services, it'd be activated
then too (for instance "Network -> Local Network" in Nautilus).
For instance, if you browse for others' shared files
("Network -> Local Network" in Nautilus) or printers, you're not making any
services available yourself, but you still need avahi-daemon running.
avahi-daemon also makes foo.local resolvable by others on your local network
segment, where foo is your hostname; I for one sometimes install avahi-daemon
just to have that side-effect, without any actual services advertised, because
the actual service I'm interested in is ssh on a well-known port.
S
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303143...@reptile.pseudorandom.co.uk
Klaus Ethgen
Hash: SHA512
Am Do den 3. Mär 2011 um 12:22 schrieb Lars Wirzenius:
> > So you contradict yourself within two paragraphs. It makes it less
> > useful to enable it only on manual intervention (say, it should be
> > enabled automatic) but on the other hand you say that nobody is forcing
> > me (or others) to use it. How do that plays together?
>
> I don't see a contradiction between "nobody is forced to use zeroconf"
> and "zeroconf is less useful if it has to be enabled manually".
That is your point of view. I see that as contradiction in some sens.
> (Yes, it would be nice if there were an easy way to disable it.)
True; or even not even installed.
> However, could we please end the FUDfest?
I do agree with youe that we should not spread FUD. But I see just
little in this thread.
Is having a other meaning than others equivalent to FUD?
> This thread seems to be quite unconstructive,
Don't think so. I gave a concrete tip to the OP.
> with unspecific claims of security problems,
Oh, there was some absolute concrete claims in that discussion. (Not
only from my side.)
> unwarranted slurs on users based on their operating system,
I didn't see any insult in this particular thread.
> and accusations on Debian developer's attitudes.
Oh, sorry, I am once burnt. The disaster with changing openssh security
checks just for the convenience of a hand full users and where the
involved DDs are unconvincable even from the openssh people them self is
just tickling in my bones. And that was not the only claim I see and
was involved in the past.
> If there is an actual problem, explain what it is, and suggest a
> solution.
For zeroconf; make it optional as the OP suggested. For the openssh
disaster, listen to the openssh people they might have more knowledge
about security. ...
There is concrete solutions given. But if nobody want to listen to
them...
> Be specific.
For my person, I think I am.
> Avoid hyperbole and vague generalities. Do not insult.
I do not see how I did. However, if someone starts to insult, I might
react also rough. I'm sorry for that.
> Write few mails, but put effort into each one.
Not less than necessary.
> If others don't agree with you, possibly you are unclear and
> they are not stupid or evil: rephrase and expand and ask questions, and
> don't get frustrated.
Sorry, english is not my mother tongue. But I try my very best.
However, if the other party do even not listen to native english
speaker who have concrete arguments...
I might be wrong in some cases. But in the security part I do not see an
alternative to be a bit to paranoid. And if I am not the only one, that
shows me that I am not completely wrong.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTW+oHZ+OKpjRpO3lAQpAjQgAmX13cByoj3eop+6jBj0+AGs5fBwT7BY3
kL/9kGLlCIrEZncK4nkJqLSITjv9lc9ZOpcCPO+BqoJRzTTe0LMaY3iGwFpM8CDw
+nsvXOyhFQbKVKqLGGGK/bjwSRlv4m8Ti4SwrtYqkA69FzamuEwXBOzzwpzbK3Ep
8kWBVyxv+8UXxKKhfXGIqvDZg/PAe3+LODxAcDysKKgVfEndi5BnpTUMT1RI4Ine
QFKYSpJwtMCR0BwMUQ3GLMZXtUp9tmrY/N3q75c0aD9LwqTUDCE8pm7NxcZhUt6Q
9Zu8ouHLBPY7KSSrv6UicYpVf6i726aD26f/q9SgI6oAwuhfhkQFqA==
=wl45
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303143...@ikki.ethgen.ch
Stig Sandbeck Mathisen
> some package announce their existance to the world without any admin
> decision
It should be a site policy.
> It is not a fud and a security hole!
I disagree.
--
Stig Sandbeck Mathisen <s...@debian.org>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
> Bastien ROUCARIES <roucarie...@gmail.com> writes:
>
>> some package announce their existance to the world without any admin
>> decision
>
> It should be a site policy.
And set to no by default or a least well documented
>> It is not a fud and a security hole!
>
> I disagree.
Giving information on my system without admin concent is an
information leak, and thus tag security...
Bastien
>
> --
> Stig Sandbeck Mathisen <s...@debian.org>
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/7xmxlcs...@fsck.linpro.no
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTikXWCpRJgX3i33Hs...@mail.gmail.com
Philipp Kern
> Giving information on my system without admin concent is an
> information leak, and thus tag security...
Information leaks are leaks of *sensitive* information. If I want to know if
you run phpmyadmin at its default location I just poll that URL and your
webserver will tell me. If you don't run it there but in another path you'll
likely not know where to change it in the Avahi broadcast data.
And next time we get bugs about Iceweasel leaking its version number in the
User-Agent header, which I consider more sensitive (cf. Panopticlick). But
then my mileage varies, as yours does, too.
We don't like security by obscurity, as you might know.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnimvf8a...@kelgar.0x539.de
Tollef Fog Heen
| main security problem is resolver,
| $host -v www.local
| www.local
| www.local.mydomain.com
So the security problem you see is that if you have a domain called
«local» the entries in it might be spoofed due to how the resolver
works?
To the extent this is a bug, it's a bug in the resolver that it does not
treat names with dots in them as absolute, but relative. I know this is
how it's been done in the past, but perhaps changing that to treating
names with as absolute would be a better solution.
Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/871v2oj...@qurzaw.varnish-software.com
Ben Hutchings
> ]] Bastien ROUCARIES
>
> | main security problem is resolver,
> | $host -v www.local
> | www.local
> | www.local.mydomain.com
>
> So the security problem you see is that if you have a domain called
> «local» the entries in it might be spoofed due to how the resolver
> works?
>
> To the extent this is a bug, it's a bug in the resolver that it does not
> treat names with dots in them as absolute, but relative. I know this is
> how it's been done in the past, but perhaps changing that to treating
> names with as absolute would be a better solution.
echo >>resolv.conf options ndots:15
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110303225...@decadent.org.uk
Tollef Fog Heen
Hi,
| On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote:
|
| > To the extent this is a bug, it's a bug in the resolver that it does not
| > treat names with dots in them as absolute, but relative. I know this is
| > how it's been done in the past, but perhaps changing that to treating
| > names with as absolute would be a better solution.
|
| echo >>resolv.conf options ndots:15
Thanks for the suggestion, but this does not seem to do what I want, I think?
ndots:n
sets a threshold for the number of dots which must appear in a name
given to res_query(3) (see resolver(3)) before an initial absolute
query will be made. The default for n is 1, meaning that if there
are any dots in a name, the name will be tried first as an absolute
name before any search list elements are appended to it. The value
for this option is silently capped to 15.
I'd like it to not append the search list if there are dots at all.
so doing «getent hosts foo.bar» will only generate a query for
«foo.bar.», not for «foo.bar.$searchpath.»
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87hbbje...@qurzaw.varnish-software.com
Sujit Karatparambil
> «foo.bar.», not for «foo.bar.$searchpath.»
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTiks+GNibGo0hadzk...@mail.gmail.com
Sujit Karatparambil
>
> Thanks for the suggestion, but this does not seem to do what I want, I think?
Another Pointer
(http://www.dd-wrt.com/phpBB2/viewtopic.php?p=344310&sid=6f3fef9df8b046ec568039de87c1175f).
> so doing «getent hosts foo.bar» will only generate a query for
> «foo.bar.», not for «foo.bar.$searchpath.»
I donot think ZeroConf works this way. This is similar to Windows or
Bonjour where there is an published service.
Could you dump some commands similar to the pointer I have given w.r.t Avahi.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimcP34oUGb4SVnW...@mail.gmail.com
Yves-Alexis Perez
> We don't like security by obscurity, as you might know.
Not shouting out loud that a service is available doesn't qualify as
“security by obscurity” for me.
Regards,
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299229274.26397.1.camel@oban
Yves-Alexis Perez
> main security problem is resolver,
> $host -v www.local
> www.local
> www.local.mydomain.com
>
> see security issue in draft paper also in case
> http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
resolver is more like the “client” side of things, while service
publication is more the “server” side of things.
If you don't want your host to resolve “local” stuff at all, you can
edit /etc/nsswitch.conf and remove the mdns stuff.
Regards,
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299229500.26397.4.camel@oban
Wouter Verhelst
> 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!
Me too, but not in all cases.
There are two generic types of computing environments. For lack of a
better name, I'll call them the environment of the home user, and that
of the corporate user, though it's not entirely accurate. Unfortunately,
their requirements conflict somewhat.
For a corporate user, security is more important than convenience. When
an intruder breaks in to a corporate network, the repercussions could be
disastrous; in the worst case, corporate spies might bring down the
company. Since corporate environments are supposed to be having system
administrators who can administrate whatever services would be required
so as to avoid security issues that might result from convenience
services, it makes sense to disable those services there and have
manually-configured services instead.
For a generic home user -- someone who isn't very familiar with
computers -- convenience is more important than security. That's not to
say such people should have completely insecure systems, but the
trade-offs between security and convenience are slightly different. For
instance, I wouldn't expect my parents to understand what a DNS server
is, let alone how to administer it; but even if that is so, they still
expect to be able to reach eachothers' laptops by using names, rather
than IP addresses (if they would even know what an IP address is, which
I doubt). A break-in on a home network is bad, but beyond privacy
issues, the repercussions would be minimal, and therefore the security
measures can be less stringent if it helps increase convenience.
Of course the two overlap somewhat -- small companies' networks might
look more like home networks, and geeks' home networks might look more
like corporate networks -- but in general, I believe the above is true.
> 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 with that, but only in the 'corporate' environment as described
above.
> > 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.
Let's just say 'end users who are not very aware of computing
technology' rather than 'mac or windows user', shall we?
There are several Debian users who fall in that category, too. And while
I agree that disabling zeroconf should be easily possible, I think a
default of 'convenience for a home user' is not a bad thing for a
distribution that is used for both corporate and home environments. Such
a default would include 'enabling zeroconf'.
[...]
> And even worse, debian is often used on server platforms where you never
> ever want to have any such magically configured services.
Since avahi isn't a dependency of anything you'd want to install on a
server -- I personally have never installed gnome on a server, for
instance -- it usually isn't.
[...]
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110304093...@celtic.nixsys.be
Klaus Ethgen
Hash: SHA512
Hi,
Am Fr den 4. Mär 2011 um 10:31 schrieb Wouter Verhelst:
[Corporate users with preference for security]
[Home users with preference for convenience]
I somewhat agree. But not in all consequence.
For that users that you call "Corporate users" I think I can fully
agree. But not with "Home users".
The reason is not that obvious but might be clear when looking to the
image, systems have in the world:
Windows: Insecure, full control, many software, games, official support
Mac: Easy, colorful, all is moving and wabbering
Debian: Secure, clear dependencies, no hidden control (that would
overwrite administrator settings), absolute control
Ubuntu: Colorful, Easy, more or less secure
SuSI^HE: Much of hidden control, insecure (somewhat, but who cares),
YaST
Redhat: Official supported, not that many packages
I left out many other systems but that should be enough to show, what I
want to show.
A user that installs Debian on his system will do that due to the
reputation in security. If he want to have a simpler system he would
install, for example, Ubuntu, Mac or Windows.
So I do not think that we should sell the reputation of a secure system
just for the convenience. But I think that, for that people who do not
care about the part of security, such services should be easily to
enable (Maybe with a debconf question that explains the consequences).
I do not think that Debian should be good for every DAU (German
abbreviation, English would be luser or so). I think Debian should be a
distribution for experts and professionals (but not exclusive).
> > 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.
>
> Let's just say 'end users who are not very aware of computing
> technology' rather than 'mac or windows user', shall we?
Well, I played intentional with the clichés as the most people (here)
would understand that it stands for them. (However, I might fail with
the idea. But see above)
And it has an other reason too I used that clichés, I do not think that
debian should reuse the errors and mistakes that systems above did do in
the past (Just think about the easy sharing stuff on early windows
(netbios and contortions, that was the target for many attacks in the
past, the designers of that services even did not think about the
problems they created). I think zeroconf with all the stuff around is on
the way to go the same way than that.
If the user want to have it, well then he should be able to do. But
debian (and in my eyes all systems) should not give them the pistol, arm
it and show them how to shoot himself in the head. We can sell them the
pistol but should prepare them about the danger it can have.
> There are several Debian users who fall in that category, too. And while
> I agree that disabling zeroconf should be easily possible, I think a
> default of 'convenience for a home user' is not a bad thing for a
> distribution that is used for both corporate and home environments. Such
> a default would include 'enabling zeroconf'.
As I told, I think that the default should be disabled (as that would
correct for most of the debian users). But I agree that the
enabling/disabling should be easy; and not only per system, zeroconf
insists on several systems like avahi, link local, mdns, ...
> > And even worse, debian is often used on server platforms where you never
> > ever want to have any such magically configured services.
>
> Since avahi isn't a dependency of anything you'd want to install on a
> server -- I personally have never installed gnome on a server, for
> instance -- it usually isn't.
True. But sometimes you need a software component on the server that you
usually only use on laptops or desktops. One example is the
wpa-supplicant, that is common to test radius servers. It should not be
that this accidentally leads to zeroconf components with the
dependencies. (I did not check if that is the case in my example above.)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTXC/oZ+OKpjRpO3lAQryLAf+NgcpUG3VmOcBVRA8LJRJDA53ep0XE+ht
UzMYSyVBX2567eecw5DbG8/7+d99MW1p9z7pl1BP42Vy8geNft2Z1iVVTEmiVIVf
G7yND/cYj8r+VkJtH3JuViITmo1AQtZgQfH+y00CLxSGtYWwEbvtFilzr5TpoT6/
m4LeVJysCb/+ojtWQm/SmcJG0RtmwGJVC66jmDbJHpJDg3VReGo0JMoqA501zrfM
gUehJ+lFz+YYnMPFvTBqocDyB693xrJ/GDW6srUEReqtcQV53J30TfyAzUQdrAPY
yY4opLXAc66NyaPDn5HqpYXFw0GoD9G3M/9V9xfzg2zkrELF3JAj7Q==
=kcRt
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011030410...@ikki.ethgen.ch
Sujit Karatparambil
> correct for most of the debian users). But I agree that the
> enabling/disabling should be easy; and not only per system, zeroconf
> insists on several systems like avahi, link local, mdns, ...
Atleast on Ubuntu You are asked if you select for optional software.
>> > And even worse, debian is often used on server platforms where you never
>> > ever want to have any such magically configured services.
>>
>> Since avahi isn't a dependency of anything you'd want to install on a
>> server -- I personally have never installed gnome on a server, for
>> instance -- it usually isn't.
>
> True. But sometimes you need a software component on the server that you
> usually only use on laptops or desktops. One example is the
> wpa-supplicant, that is common to test radius servers. It should not be
> that this accidentally leads to zeroconf components with the
> dependencies. (I did not check if that is the case in my example above.)
>
Agree zeroconf is something similar and seems to have misquoted in this case.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimCvjdfVyVwuf7Ee...@mail.gmail.com
Andrei Popescu
>
> The reason is not that obvious but might be clear when looking to the
> image, systems have in the world:
> Windows: Insecure, full control, many software, games, official support
> Mac: Easy, colorful, all is moving and wabbering
> Debian: Secure, clear dependencies, no hidden control (that would
> overwrite administrator settings), absolute control
> Ubuntu: Colorful, Easy, more or less secure
> SuSI^HE: Much of hidden control, insecure (somewhat, but who cares),
> YaST
> Redhat: Official supported, not that many packages
I thought Debian was "The Universal Operating System" ;), so I would
rather divide like this:
GNOME/KDE system: lots of functionality out-of-the-box
XFCE/LXDE system: decent functionality, usable also on older machines
WM/console system: packages only installed as needed
I expect a *typical* user of the first two categories to appreciate the
functionality provided by zeroconf. If they know what it is they will
also be capable of getting rid of it if they so desire, it's not that
difficult even with Gnome where the main meta-package directly depends
on avahi-daemon.
Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Wouter Verhelst
> A user that installs Debian on his system will do that due to the
> reputation in security. If he want to have a simpler system he would
> install, for example, Ubuntu, Mac or Windows.
> I do not think that Debian should be good for every DAU (German
> abbreviation, English would be luser or so). I think Debian should be a
> distribution for experts and professionals (but not exclusive).
This is where we disagree.
You seem to believe that Debian's usefulness should be confined to a
particular niche of users; a niche which conveniently includes you.
I disagree. While it certainly would make your particular use case
easier, I think Debian should strive to be useful to as many users as
possible. This isn't always possible (for instance, Debian will most
likely never be very useful to people who only want to use Microsoft
Office), but that should not interfere with the desire to strive for
that end goal.
Just because Ubuntu is a popular distribution for beginning Linux users
should not have to mean that 'beginning Linux users' is no longer a
target audience for Debian.
If security matters a great deal to you, you should audit systems for
unwanted services and disable them, rather than hope that whatever you
have installed happens not to be a problem for your particular use case.
Relying on defaults to be secure is relying on other people to do your
security for you. This is stupid, in all cases. That's not to say that
our defaults should be insecure, but 'acceptable security' is a
stretchable concept; the security trade-offs that you are willing to
live with may be stricter than mine, and vice versa.
If you're unfamiliar with computers, on the other hand, chances that
you'll be able to figure out how to enable convenience services are
slim, at best. Since home users typically use computers in a desktop
environment, I therefore think it's perfectly okay to have the default
desktop installation enable such convenience services.
Klaus Ethgen
Hash: SHA512
Hi,
Am Fr den 4. Mär 2011 um 12:19 schrieb Andrei Popescu:
> I thought Debian was "The Universal Operating System" ;), so I would
> rather divide like this:
>
> GNOME/KDE system: lots of functionality out-of-the-box
> XFCE/LXDE system: decent functionality, usable also on older machines
> WM/console system: packages only installed as needed
Hey, I feel discriminated! I use fvwm. ;-)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTXDMBZ+OKpjRpO3lAQqHrggArd3xugZ3qilOdf8h2qP2L8EQMaiuw/e4
lEZwDZ70uSgHMWc55E3UfC2UWCwzIU9IZVzn9S71QMmZPtB6Jxpl50vWgf0Xk74b
796wgRuE6+iYvL5EID87AtbyYgcOQ4J/RXFkOjT4yqC44FY1knxbXdb5M0L9HAQZ
hsvM2s9XaMFVhmrsLA6WpFJU7FkOHrpD8o6d12NetdbSXP7PalMs2EN63BDncYcs
yPdhh7Vg5K9a6Cs0xpTaXQE/iqzZ9M6PS895E3mfUS+roAvJnpN3I4f2oRFWemKe
oQ6bCLtszWYINKOIUYly+WFxDJR16T6xLQysEOfl4mXHPIAikPwRRQ==
=8Fs9
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011030411...@ikki.ethgen.ch
Philip Hands
...
> I don't need not want avahi, it actually two or three times broke
> my network by doing changes to config file I don't want (don't remember
> the details) and at that time I could purge it away, but it came back
> again.
This is exactly my experience of avahi.
Clearly, this is the reason that people end up developing an irrational
hatred of avahi -- if there was anything about it that I wanted, then
I'd have decided to install it, and so if there were any issues with it,
it would be my fault for installing it, but since I'm not aware of ever
having needed it, and since I don't use gnome (although I occasionally
install gnome-ish things, which is probably the thing that drags it back
in again) it's always a surprise when I notice it on my machine, and of
course, it's always a nasty surprise, because when it's doing what it's
supposed to do I won't notice it, so the fact that I've noticed it means
that something has gone weird with my network (quite possibly unrelated
to avahi) and as a result avahi has allocated one of it's 169.254.*
addresses, which I never want it to do, so when I see them I blame the
unexpected network behaviour on avahi.
You might say that I should at that moment report a bug against avahi,
but of course in order to diagnose the network problem, I'm sure I don't
want what avahi's doing, so I get rid of it, and then I fix whatever the
problem really was, but am left with the suspicion that avahi was at
least partially to blame.
If the avahi developers want to attract less ire, they should provide us
with a way of saying that we don't want it. If that causes things to
break, then that's fine as it will educate all of us avahi-haters to
understand the benefit that it provides.
I'm aware that I could do something similar to enricos-sanity, and
routinely install a dummy package that conflicts with avahi, but I had
rather hoped that this issue would at some point be resolved in standard
Debian by either reducing the number of packages that declare
dependencies/recommends against avahi, or that the avahi packages might
provide a debconf question about it, or some other way of declaring that
one doesn't want such stuff.
This is not avahi specific -- I have similar issues with resolvconf, on
the basis that whenever I notice it on any of my machines, it's because
it's applied one of it's simple-minded assumptions to a machine with a
complicated network setup, and thus broken things. The difference is
that I've not noticed resolvconf sneaking back onto machines where I've
removed it.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
Ben Hutchings
> On Thu, Mar 03, 2011 at 11:02:47AM +0100, Klaus Ethgen wrote:
> > 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!
>
> Me too, but not in all cases.
>
> There are two generic types of computing environments. For lack of a
> better name, I'll call them the environment of the home user, and that
> of the corporate user, though it's not entirely accurate. Unfortunately,
> their requirements conflict somewhat.
>
> For a corporate user, security is more important than convenience.
This is nonsense. Corporate users need to get stuff done. To the
extent that an IT department issues security policy that get in the way
of that, the IT department is undermining the company and will be
ignored. Thankfully, security rarely needs to conflict with
convenience.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Ben Hutchings
> ]] Ben Hutchings
>
> Hi,
>
> | On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote:
> |
> | > To the extent this is a bug, it's a bug in the resolver that it does not
> | > treat names with dots in them as absolute, but relative. I know this is
> | > how it's been done in the past, but perhaps changing that to treating
> | > names with as absolute would be a better solution.
> |
> | echo >>resolv.conf options ndots:15
>
> Thanks for the suggestion, but this does not seem to do what I want, I think?
>
> ndots:n
> sets a threshold for the number of dots which must appear in a name
> given to res_query(3) (see resolver(3)) before an initial absolute
> query will be made. The default for n is 1, meaning that if there
> are any dots in a name, the name will be tried first as an absolute
> name before any search list elements are appended to it. The value
> for this option is silently capped to 15.
>
> I'd like it to not append the search list if there are dots at all.
You could stop being lazy and type the dot on the end too. ;-)
> so doing «getent hosts foo.bar» will only generate a query for
> «foo.bar.», not for «foo.bar.$searchpath.»
I misparsed your question because I assumed you were addressing the
issue that Bastien pointed out in the message you replied to:
> main security problem is resolver,
> $host -v www.local
> www.local
> www.local.mydomain.com
And I believe that the 'ndots' option does address that issue - to an
extent. You still need DNSSEC or application-layer security to verify
the answer, regardless of the presence of mDNS.
Yves-Alexis Perez
> If you're unfamiliar with computers, on the other hand, chances that
> you'll be able to figure out how to enable convenience services are
> slim, at best. Since home users typically use computers in a desktop
> environment, I therefore think it's perfectly okay to have the default
> desktop installation enable such convenience services.
Note that if you're unfamiliar with computers, it's helpful to be able
to trust the default install to “do the right thing” too wrt. security.
Even if “home user” might not have security concerns as high as
“business users”, I think they'd prefer their private stuff to stay
private, wether it's their family pictures, their bank account stuff, or
something else. It applies to various other threats too.
Regards,
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299242855.26397.17.camel@oban
Philipp Kern
> I'd have decided to install it, and so if there were any issues with it,
> it would be my fault for installing it, but since I'm not aware of ever
> having needed it, and since I don't use gnome (although I occasionally
> install gnome-ish things, which is probably the thing that drags it back
> in again) it's always a surprise when I notice it on my machine, and of
> course, it's always a nasty surprise, because when it's doing what it's
> supposed to do I won't notice it, so the fact that I've noticed it means
> that something has gone weird with my network (quite possibly unrelated
> to avahi) and as a result avahi has allocated one of it's 169.254.*
> unexpected network behaviour on avahi.
Interestingly long sentence for an Englishman. Anyway: That's a feature
of avahi-autoipd, not avahi-daemon. avahi-daemon shouldn't mess with
your networking, and avahi-autoipd is just a suggestion by avahi-daemon,
not even a recommends (and it seems to be a suggests of various other
packages as well, like isc-dhcp-client and network-manager).
The other part that might mess with your network is libnss-mdns. That one was
regularly pulled in some years back and broke all installations that used the
.local suffix for their local network. This one is a recommends of
avahi-daemon. It won't cause a 169.254/16 to appear, but it might break
DNS name resolution in intersting ways.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnin1nhc...@kelgar.0x539.de
Olaf van der Spek
> You could stop being lazy and type the dot on the end too. ;-)
You can't expect everyone to type a dot after every single domain name they use.
Olaf
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTimTneETbdrpTQwG3Y0hFU1T9XbeWu=kSnw...@mail.gmail.com
Wouter Verhelst
> On Fri, 2011-03-04 at 12:24 +0100, Wouter Verhelst wrote:
> > If you're unfamiliar with computers, on the other hand, chances that
> > you'll be able to figure out how to enable convenience services are
> > slim, at best. Since home users typically use computers in a desktop
> > environment, I therefore think it's perfectly okay to have the default
> > desktop installation enable such convenience services.
>
> Note that if you're unfamiliar with computers, it's helpful to be able
> to trust the default install to “do the right thing” too wrt. security.
> Even if “home user” might not have security concerns as high as
> “business users”, I think they'd prefer their private stuff to stay
> private, wether it's their family pictures, their bank account stuff, or
> something else. It applies to various other threats too.
Certainly; if my mail gave you the impression that I was suggesting that
security is not at all important for the home user, then the intended
message failed to come across.
What I meant to say is that the trade-off is vastly different; whereas
'if in doubt, choose the option that is more secure but requires (much)
more manual maintenance' is the right choice for corporate environments,
the same is certainly not true for home users.
I'm not at all suggesting that we change the default sshd configuration
to have the equivalent of 'PermitEmptyPasswords yes', for instance. But
announcing hostnames is not quite in the same ballpark.
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110304142...@celtic.nixsys.be
Klaus Ethgen
Hash: SHA512
Am Fr den 4. Mär 2011 um 12:24 schrieb Wouter Verhelst:
> On Fri, Mar 04, 2011 at 11:32:01AM +0100, Klaus Ethgen wrote:
> > A user that installs Debian on his system will do that due to the
> > reputation in security. If he want to have a simpler system he would
> > install, for example, Ubuntu, Mac or Windows.
> [...]
> > I do not think that Debian should be good for every DAU (German
> > abbreviation, English would be luser or so). I think Debian should be a
> > distribution for experts and professionals (but not exclusive).
[...]
> You seem to believe that Debian's usefulness should be confined to a
> particular niche of users; a niche which conveniently includes you.
Well, I wouldn't tell it »niche« but in principle you are right.
> I disagree. While it certainly would make your particular use case
> easier,
That is not the point. In fact, it makes many thinks harder.
> I think Debian should strive to be useful to as many users as
> possible.
True, but ...
> Just because Ubuntu is a popular distribution for beginning Linux users
> should not have to mean that 'beginning Linux users' is no longer a
> target audience for Debian.
It is definitively not. That is the reason, why so many derived
distributions of debian exists (Knoppix, Ubuntu, Kubuntu, ...).
> If security matters a great deal to you, you should audit systems for
> unwanted services and disable them,
True. But that is not the point. That is always needed, independent if
your defaults are secure or not.
> rather than hope that whatever you have installed happens not to be a
> problem for your particular use case. Relying on defaults to be secure
> is relying on other people to do your security for you.
Hmmm... First you tell that debian should be for beginning users too and
then you tell that they couldn't relay on the security of the system!?
And this is exact the point. Just because it needs further steps to
install a secure system do not mean that the defaults could be insecure.
In ancient times debian was packaged the way that the administrator only
installed the daemons that he needed. Today many daemons gets installed
by dependencies and gets started without any need. Just the fact is
security relevant as any running daemon higher the change that there is
a security hole. Every daemon! And examples are found at many places
today. I. e. mysqld from kde packages, apache for a linkchecker, avahi
and consortions for gnome, ... Not to mention all the daemons that do
not listen on network as gconf, kded4, ...
I think, in the last few years, the quality of (some) debian packages
has sunken. But this is just my personal view, and I am sorry to say it.
> This is stupid, in all cases.
When you argue that debian should be for beginning users too, no. In the
other case just partly.
> That's not to say that our defaults should be insecure, but
> 'acceptable security' is a stretchable concept;
But has its borders too. And having unnecessary daemons run and listen
for network answers is definitively beyond that border.
> the security trade-offs that you are willing to live with may be
> stricter than mine, and vice versa.
I think so. (From the reading)
> If you're unfamiliar with computers, on the other hand, chances that
> you'll be able to figure out how to enable convenience services are
> slim, at best.
Look, I installed my mother a system with debian on it. And I activate
all that is needed to have her use the system. But I would never ever
gave her a debian cd and tell her to install the system herself. This
means that I have the responsibility to hold the system secure and up to
date, true.
> Since home users typically use computers in a desktop environment, I
> therefore think it's perfectly okay to have the default desktop
> installation enable such convenience services.
No. Not with an distribution than debian but maybe with such than
ubuntu. Just open the eyes. Debian _is_ not for the very begining
(linux) user. Debian is (or was until now) a highly professional linux
distribution that fits the needs of secure and flexible environments,
where a big part is servers.
If you want to change debian to be ubuntu it would be the time to look
for another distribution that can be used on servers. (unfortunately I
do not know an alternative.)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Kl...@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTXD+WZ+OKpjRpO3lAQrBzgf+NtC9f8snBriRsQwwM7nNf5/b+I1b4LIN
ZAZYWIFjck9Mc1h8rpmqt2QsCuEtRFEwtFlkTl5MmCTUOD3neTND9f/R/CmZtt04
KjqdaUHe1dqwoSleeLaw1z5LeFnKPz+grvvvtsAOjTXwxLnnRLXVdBZZAKRc69FC
8c7ivluaABnjyVeH2ea7Eh4Xub8i32hy/N6yqnTNd7Jygglq06BLQ2GqgSfUK56A
UknNIK9hmKY3sdVQ2d97lgJ0vPls4EvA9glWNQnTYXgBeuu2oW4Gcx1tqTzHgrGH
oC64saIpwp0u9wxKWr/StYL6V5KpiPrP/CsTzMnRgNnnuh5eUCtw+A==
=Oh2R
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011030414...@ikki.ethgen.ch
Olaf van der Spek
> In ancient times debian was packaged the way that the administrator only
> installed the daemons that he needed. Today many daemons gets installed
> by dependencies and gets started without any need. Just the fact is
> security relevant as any running daemon higher the change that there is
> a security hole. Every daemon! And examples are found at many places
> today. I. e. mysqld from kde packages, apache for a linkchecker, avahi
> and consortions for gnome, ... Not to mention all the daemons that do
> not listen on network as gconf, kded4, ...
Daemons that don't listen on a public interface are less of an issue.
But in general I agree, daemons shouldn't run without need, especially
not on public interfaces.
> I think, in the last few years, the quality of (some) debian packages
> has sunken. But this is just my personal view, and I am sorry to say it.
>
> If you want to change debian to be ubuntu it would be the time to look
> for another distribution that can be used on servers. (unfortunately I
> do not know an alternative.)
Actually "Ubuntu ships with no open ports on public interfaces" (by default).
It's also silly to launch another distro just because some settings
have to be changed.
--
Olaf
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTin79bF3bbeNVV=R_fUy_2=TxHj2ycz...@mail.gmail.com
Paul Wise
> If you want to change debian to be ubuntu it would be the time to look
> for another distribution that can be used on servers. (unfortunately I
> do not know an alternative.)
Ubuntu actually has better pro-active/defence-in-depth security than
Debian right now. For example compiler hardening flags, kernel
hardening (symlink, hardlink, ptrace, nx emulation), MAC (AppArmour).
Perusing their roadmap pages is quite interesting too:
https://wiki.ubuntu.com/SecurityTeam/Roadmap
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTim8fdbUyz48C4jNaS5thVEWiMJfG=qvkkB...@mail.gmail.com
Yves-Alexis Perez
> Ubuntu actually has better pro-active/defence-in-depth security than
> Debian right now. For example compiler hardening flags, kernel
> hardening (symlink, hardlink, ptrace, nx emulation), MAC (AppArmour).
> Perusing their roadmap pages is quite interesting too:
>
> https://wiki.ubuntu.com/SecurityTeam/Roadmap
Note that we do try to improve that in Debian too. See #552688,
http://lists.debian.org/debian-devel-announce/2011/01/msg00006.html,
#605090 (though it's not about the default install).
Regards,
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1299254746.26397.23.camel@oban
Bastien ROUCARIES
> On Thu, Mar 03, 2011 at 11:02:47AM +0100, Klaus Ethgen wrote:
> > Hi,
> > And even worse, debian is often used on server platforms where you never
> > ever want to have any such magically configured services.
>
> Since avahi isn't a dependency of anything you'd want to install on a
> server -- I personally have never installed gnome on a server, for
> instance -- it usually isn't.
>
> [...]
Except in a workstation place.
In a uni we use your workstation during the days for teaching and the night for grid computing. And we care both about security
and about using gnome.
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201103041929.37908...@gmail.com
Andrei Popescu
> >
> > Since avahi isn't a dependency of anything you'd want to install on a
> > server -- I personally have never installed gnome on a server, for
> > instance -- it usually isn't.
> >
> > [...]
>
> Except in a workstation place.
>
> In a uni we use your workstation during the days for teaching and the
> night for grid computing. And we care both about security and about
> using gnome.
If you have trouble un-installing avahi-daemon from those systems feel
free to contact debian-user for support ;)
Adam Borowski
> On Vi, 04 mar 11, 19:29:36, Bastien ROUCARIES wrote:
> > Except in a workstation place.
> >
> > In a uni we use your workstation during the days for teaching and the
> > night for grid computing. And we care both about security and about
> > using gnome.
>
> If you have trouble un-installing avahi-daemon from those systems feel
> free to contact debian-user for support ;)
You'll then have to install every bit of gnome by hand, since the
meta-packages depend on avahi.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam Borowski
> On Fri, Mar 4, 2011 at 3:59 PM, Klaus Ethgen <Kl...@ethgen.de> wrote:
> > In ancient times debian was packaged the way that the administrator only
> > installed the daemons that he needed. Today many daemons gets installed
> > by dependencies and gets started without any need.
> > If you want to change debian to be ubuntu it would be the time to look
> > for another distribution that can be used on servers. (unfortunately I
> > do not know an alternative.)
>
> Actually "Ubuntu ships with no open ports on public interfaces" (by default).
[~]# netstat -ap|grep avahi
udp 0 0 *:mdns *:* 1622/avahi-daemon:
udp 0 0 *:45282 *:* 1622/avahi-daemon:
udp6 0 0 [::]:mdns [::]:* 1622/avahi-daemon:
udp6 0 0 [::]:58036 [::]:* 1622/avahi-daemon:
I admit I didn't notice this before, as I would never expect a _client_
system to have some crap listening by default. And it is world-reachable
-- am I supposed to ensure the top s1kr3t address
2001:6a0:118:0:22cf:30ff:fec3:d4b7 never leaks out? (oops...)
And why does it open this security hole? To make it slightly easier to
configure link-local instant messages. Who exactly is going to need that
these days? The times of local networks disconnected from the world are
mostly over. You have some non-networked machines here and there, but if
there's a network of some kind, it almost always is globally connected.
These few places that do have airwalled networks definitely don't want to
run link-local chat...
So, any gain is infinitessimally small, and the risk is real. Even daemons
coded by most security-minded people that have seen a lot of review do have
exploitable holes once in a while, so I expect Avahi to fare no better.
Like, for example, #614785.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
Not completly, it is a global default. I will prefer that mdns will be always solve as absolute name but want to use default for
dns
BTW ndots seems broken at least in my installation and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/401202
Bastien
Bastien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201103042056.31423...@gmail.com
Scott Kitterman
This is actually a documented [1] exception to the general policy of no open
ports (not one I agree with BTW). The rationale is provided at [2].
[1] https://wiki.ubuntu.com/Security/Features#ports
[2] https://wiki.ubuntu.com/ZeroConfPolicySpec
What I did was change /etc/avahi/avahi-daemon.conf so it says:
use-ipv4=no
use-ipv6=no
I'm pretty sure that makes it safe (and was easier than dealing with the
dependency issues associated with trying to remove it). netstat -ap|grep
avahi returns nothing on such a system.
Scott K
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201103041535...@kitterman.com
Steve Langasek
> And why does it open this security hole? To make it slightly easier to
> configure link-local instant messages. Who exactly is going to need that
> these days? The times of local networks disconnected from the world are
> mostly over. You have some non-networked machines here and there, but if
> there's a network of some kind, it almost always is globally connected.
> These few places that do have airwalled networks definitely don't want to
> run link-local chat...
"If there's a network of some kind". What about ad-hoc connections between
two or more laptops / tablets / mobile devices? The hardware supports this
mode of operation just fine; shouldn't our software as well? I shouldn't
need to carry an AP with me, or send all my traffic to a telco, or use a
sneakernet, to share files with you when we're in the same room.
All of these devices need to be proofed against hostile networks /in
general/; advertising services on such a network is a pretty small risk in
comparison to the risk of connecting to an untrusted network in the first
place.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Sujit Karatparambil
donot think people
who are just talking with sheer imagination with computer illiteracy
to come here.
This is high volume site. People over here do some real work. It cannot be used
to malice a set of people.
> [~]# netstat -ap|grep avahi
> udp 0 0 *:mdns *:* 1622/avahi-daemon:
> udp 0 0 *:45282 *:* 1622/avahi-daemon:
> udp6 0 0 [::]:mdns [::]:* 1622/avahi-daemon:
> udp6 0 0 [::]:58036 [::]:* 1622/avahi-daemon:
Down Comment.
> I admit I didn't notice this before, as I would never expect a _client_
> system to have some crap listening by default. And it is world-reachable
> -- am I supposed to ensure the top s1kr3t address
> 2001:6a0:118:0:22cf:30ff:fec3:d4b7 never leaks out? (oops...)
Where is the client in this? I donot get what you mean by a client.
Could you tell
me in Avahi what is a client.
> And why does it open this security hole? To make it slightly easier to
What security hole?
> configure link-local instant messages. Who exactly is going to need that
> these days? The times of local networks disconnected from the world are
Donot get what you mean.
> mostly over. You have some non-networked machines here and there, but if
> there's a network of some kind, it almost always is globally connected.
> These few places that do have airwalled networks definitely don't want to
> run link-local chat...
what do you mean by airwalled network? could you give some specific example.
> So, any gain is infinitessimally small, and the risk is real. Even daemons
> coded by most security-minded people that have seen a lot of review do have
> exploitable holes once in a while, so I expect Avahi to fare no better.
Could you get specific with the security holes to be looked for ?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTiUWr9XyxC5azHTez...@mail.gmail.com
Osamu Aoki
On Fri, Mar 04, 2011 at 08:10:01PM +0100, Adam Borowski wrote:
> On Fri, Mar 04, 2011 at 08:56:46PM +0200, Andrei Popescu wrote:
> > On Vi, 04 mar 11, 19:29:36, Bastien ROUCARIES wrote:
> > > Except in a workstation place.
...
> > If you have trouble un-installing avahi-daemon from those systems feel
> > free to contact debian-user for support ;)
>
> You'll then have to install every bit of gnome by hand, since the
> meta-packages depend on avahi.
By *hand* is not really a trouble if you have handy *hand* like aptitude
(few key strokes). If you think to do this only via apt-get, it is a
trouble you may not wish to deal with. This is really a user
configuration issue of an user with special itch to the detail. Use the
right tool.
Osamu
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Maximiliano Curia
> Does avahi could be disable (using kernel level firewalling is not from my
> point of view a solution) ?
# update-rc.d avahi-daemon disable
Does the job for me.. :)
Anyway, I'll need a puppet (or similar) rule to maintain this for my users, on
upgrades, etc.
--
Saludos,
Maxy
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/a8ka48-...@freak.gnuservers.com.ar