From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id A278D28B23 for ; Fri, 8 Mar 2024 14:30:58 +0100 (CET) Received: (qmail 1669 invoked by uid 550); 8 Mar 2024 13:26:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1634 invoked from network); 8 Mar 2024 13:26:55 -0000 Date: Fri, 8 Mar 2024 08:31:02 -0500 From: Rich Felker To: David Schinazi Cc: musl@lists.openwall.com Message-ID: <20240308133102.GN4163@brightrain.aerifal.cx> References: <20240306161544.GH4163@brightrain.aerifal.cx> <20240307024316.GI4163@brightrain.aerifal.cx> <20240308000818.GJ4163@brightrain.aerifal.cx> <20240308025204.GK4163@brightrain.aerifal.cx> <20240308034740.GL4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] mDNS in musl On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinazi wrote: > Thanks. How would you feel about the following potential configuration > design? > * Add a new configuration option "send_mdns_unicast" > * When true, use the current behavior > * When false, send the query on all non-loopback non-p2p interfaces > * Have send_mdns_unicast default to false > > I was thinking through how to pick interfaces, looked up what other mDNS > libraries do, and pretty much all of them don't allow configuring > interfaces, whereas Avahi exposes allow-interfaces and deny-interfaces. I'm > leaning towards not making this configurable to reduce complexity. I think > that anyone interested in that level of config is probably using Avahi > anyway. > > Additionally this design has two nice properties: the default behavior is > RFC-compliant, and it means that for my use-case I don't need to change the > config file, which was a big part of my motivation for doing this inside of > musl in the first place :-) As discussed in this thread, I don't think so. The biggest problems I initially brought up were increased information leakage in the default configuration and inability to control where the traffic goes when you do want it on. The above proposal just reverts to the initial, except for providing a way to opt-out. For the most part, mDNS is very much a "home user, personal device on trusted network" thing. Not only do you not want it to default on because a lot of systems will be network servers on networks where it's not meaningful (and can be a weakness that aids attackers in lateral movement), but you also don't want it on when connected to public wifi. For example if you have an open browser tab to http://mything.local, and migrate to an untrusted network (with your laptop, tablet, phone, whatever), now your browser will be leaking private data (likely at least session auth tokens, maybe more) to whoever answers the mDNS query for mything.local. Windows has a setting when you add wifi networks for whether they're treated as private/trusted or public. I would guess it controls whether mDNS is used, among other things like SMB scanning or whatever. The same really belongs in a network configurator for Linux-based personal devices. Fortunately, I think an approach where you opt-in particular interfaces/source-addresses, rather than send everywhere by default, has lower implementation cost and complexity on top of being the safe thing to do. So none of the above should be taken as a "no" for the functionality, just a no for "on by default and send everywhere". Regarding untrusted networks, one thing I hadn't considered yet is that a network configurator probably needs a way to setup resolv.conf such that .local queries temp-fail rather than perma-fail (as they would if you just sent the query to public dns) to use during certain race windows while switching networks. IOW "send .local queries to configured nameservers" and "treat .local specially but with an empty list of interfaces to send to" should be distinct configurations. Rich