New ZeroConf Spec

[Ian Jackson]

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.

Like almost any new software, service, facility, protocol, or other
functionality, this plan increases the risks to the security of the
system.  As with any deployment, these risks need to be weighed
against the benefits of the proposed change.

The main risks with ZeroConfPolicySpec as I see them are described
below, along with my recommendations for Ubuntu:

 * avahi would be an additional piece of software exposed directly and
   permanently to hostile network traffic initiated outside the
   current host.  Currently Ubuntu has very few such pieces of
   software - pretty much, only the kernel is so exposed.  The `no
   open ports' policy is a good rule of thumb, intended to keep things
   this way.

   I have no clear idea about the complexity, implementation quality
   and security record of avahi.  The decision to deploy avahi in this
   way should be made after a review of its size and history.  The
   discussion in ZeroConfPolicySpec is not particularly helpful for
   this; the referenced avahi wiki page SecurityConsiderations [1] is
   interesting, but we should make up our own mind.

   Note that offering the user the choice between `keep your computer
   secure' and `get your work done' is not IMO an acceptable answer to
   difficult decisions of this kind.  A user confronted by such a
   choice is generally lacking in the knowledge and experience which
   would allow them to make the tradeoff appropriately.

   Furthermore, because this question (whether asked as a dialogue, or
   arising from a request by someone to `turn on zeroconf') will occur
   in the context of a particular task and there is a lot of evidence
   (eg, try reading the literature about safety) to suggest that
   people are very bad at making these kind of decisions in such a
   context.

 * mdns service discovery's basic design is to allow all
   `locally-connected' systems to determine amongst themselves which
   names correspond to which services.  (By its very design, it is
   intended to put flexibility and convenience ahead of security.)

   It is an explicit design goal that any machine can claim ownership
   of any name in the mdns (*.local) namespace; preventing machines
   from `masquerading' as each other is explictly excluded from the
   goals.

   With wired networks this is relatively safe in a small and
   relatively trusted group but with the increasing prevalence of
   wireless networking it will be difficult to exclude uninvited
   guests from `participating'.  Suitable link-layer authentication
   and encryption could be used to mitigate this risk but there is no
   description in the ZeroConfPolicySpec of anything of this kind.

   So I conclude that many users who use avahi and mdns on wireless
   networks, in the currently anticipated setup, will be unwittingly
   opening themselves to `sharing' with anyone in the neighbourhood
   (or of course anyone further away with a sufficiently good
   antenna).

   This defect should be remedied before this spec is implemented.

 * libnss-mdns is a new resolver library component which will process
   replies from mdns servers.  AIUI it listens on the network in
   almost the same way as a normal resolver: that is to say, it
   accepts network traffic when it has a query on the go, using a
   port allocated by the kernel from the client range.

   This introduces a new piece of security-critical software.  We
   should consider the size, history, and maintenance approach of
   libnss-mdns.  libresolv (which it's probably based on) has had a
   somewhat chequered history, so this is not an entirely theoretical
   concern.

 * The expected user behaviour is to enable sharing of certain local
   services - primarily, filesharing.  We need to consider the whole
   system and user behaviour implied by the use cases, rather than
   just the mdns part.

   The mechanisms for enabling sharing of these services need to be
   clearly set out as part of the spec.  For those services where
   sharing is already possible via the UI, this should be stated.  In
   all cases the security implications should be considered.

   The lack of information about this aspect of the setup is, I think,
   a weakness which should be remedied before the spec is implemented.

Ian.

[1] http://avahi.org/wiki/SecurityConsiderations