New ZeroConf Spec, course for edgy and proposed course for edgy+n

[Martin Pitt]

Hi,

Ian Jackson [2006-07-17 17:25 +0100]:
> I suppose after my somewhat catty contributions earlier (sorry), I
> should try to do something resembling a security review of mdns
> service discovery for Ubuntu as described in
> https://wiki.ubuntu.com/ZeroConfPolicySpec.

thanks to Ian for the analysis.

Sorry for the lengthy mail, but some detailled half-official statement
is in order, I believe.

I read the majority of this mega-thread now, as well as Lennart's
recent blog entry [1] (which was fairly informative IMHO).

I see that zeroconf is an exciting new technology, and I do not
neglect the benefits in user experience. However, I know that the
often-cited 'normal user' here does not think in terms of
authentication and security, but in terms of the goal he wants to
achieve, and how to achieve it most easily. In that regard, it is my
strong opinion that the general idea of 'zero configuration' is
flawed, since it makes it way too easy to trick people into using an
unintended/malicious service. One example is the already cited cups
browsing, another would be file sharing with a previously unknown
host. In real life, people *do* make an explicit choice about which
bank, bakery, or doctor they trust. The same minimal level of *active*
choice has to happen in computer networks IMHO. In other words, making
it *too* easy to use a remote service is a dangerous road, and I am
willing to prevent that (in a default installation) even if it causes
bad press reactions.

However, I do appreciate the reasoning about our imperfect 'no open
ports' implementation wrt. to DHCP and DNS. Both technologies make it
easy to trick an user into joining a rogue network and talk to remote
computers which aren't the ones the user intended to contact (and not
more - it is not possible (or, at least, very hard) to exploit DHCP
responses to get root privileges in Ubuntu, sinde the DHCP client does
not run as root). Also, people working on laptops and are travelling a
lot are not interested at all in IP verification, since they will
gladly accept any IP that allows them to get online. 

It is practially impossible to have IP/DHCP authentication in a
nonintrusive and reasonable "Ubuntuish" way. That's why applications
perform the authentication at the application level, like SSH checking
host keys and refusing to login, Firefox warning about bad
certificates, VPNs using cryptographically strong
encryption/authentication, etc. Of course there are people who just
click them away, but that's not something we can ever solve
technically, and doesn't belong here.

Conclusively, we should update our trust model like this: We cannot
not put trust into IP addresses and *offered* services, but we have to
authenticate those services which actually requested by the user. In
that model, our current policy wrt. DNS and DHCP, as well as the
SSH/Firefox/SSL/other application behaviour is consistent.

Therefore avahi and .local mdns service discovery turned on by default
wouldn't compromise our trust model in a significant way, *under the
condition* that avahi actually does what it claims. Also, applications
have to default to *not* use the offered services, enabling them has
to stay an educated choice of the user.

Avahi and zeroconf are still relatively new technologies (compared to
the proven DHCP client at least), and thus a certain level of
cautiousness is in oder. So far, Ubuntu has been pretty conservative
wrt.  security, and switching a new technology from 'not present' to
'automatically on' just feels wrong at least to a paranoid
security-inclined guy like me. Therefore, the current course of action
is:

 * Edgy will make it very easy to enable avahi (in the network
   administration), but will ship with avahi disabled by default. This
   allows people to play with it easily, and allows us to collect
   experience. Given Edgy's status in the release process, this is not
   subject to discussion any more.

 * In a future release (edgy+1 or 2), when we can put sufficient trust
   into avahi and have some real-world experience, we should enable
   Avahi/mDNS by default. At that point, our security policy will be
   consistent again: We would ship no open TCP ports by default (i. e.
   application level), but we would have some open UDP ports for
   service discovery. (DISCLAIMER: this is *not* an official
   commitment; this needs to be discussed and approved as an Edgy+n
   spec; I do not have the power to do this decision on my own, but I
   I have some influence to it).

I hope this is a compromise which is not too bad, suits the more
conservative fraction, and opens a perspective for those wanting the
'latest crack of the day' (in no way meant in a negative sense).

Thank you,

Martin

[1] http://0pointer.de/blog/projects/zeroconf-ubuntu

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060731/cb20b755/attachment.pgp