Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp2930120ybx; Fri, 8 Nov 2019 11:25:01 -0800 (PST) X-Google-Smtp-Source: APXvYqyeII8ZGxWXE81Nl0jBF77EqbauSbfRHvnyTAzc+M1d2FLcLn79t64dI5iTLwI8BtA9xs2Z X-Received: by 2002:a50:8a88:: with SMTP id j8mr12654195edj.35.1573241101009; Fri, 08 Nov 2019 11:25:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573241101; cv=none; d=google.com; s=arc-20160816; b=cPdoCrLa6LEzg75J6oN8k55r3CIDQXr5+rC0YFiheVKrs8g4q1AUnQjE8H/dbiWnw1 nYi9j7qnbzCb3Y0TunGG/VUVky918seTE25X0bPlZe7acREfbkfvNw87BwICBoUur92x S8gjhukKGqYvVgnCdANvOobgfSPEyvrPbg7uwlkD/bFRY5vuFLgcGkln51GzMp34OOlM LoRzXjo92u7CzTYHQGlUD2U0lO2aMm/bFhcS5l0tXkMBquZHf9N2q7slmJypERWMNOQJ boeJMV2sgALPFbGBGPvcMV88Z3jE97VXcQSDFyLbfoJeI4pPfWOk52JPz+rLLsHWfMKc IDIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=rSeEzJJFL2J46kppo+eAa64DAYEYghhg+PgDA1kJZ2g=; b=Rak+bV10yC4/ldwezq0KOUSQEkWm7A10wL5w3iI1wslR0ZhKfy2L00P9oR/sokPQLX rp5LI58ISabo2Dv0jIZTEzvAx4rED84zuL36yPNy0fJDolzqo+wPUCoHnKk4i6nvnWKq ApoudQiyUjkfLEeRDxLId2KeID1whLmq77mMRmeEMSetlMAzKntYbwRzcSGGwQlQb2yQ Ja/QhikOreGayfkRjmqwpij2xIzxbZJtJNrBiGlh3AQqcJE1tHUtaeoFLunbZX3YAa2Y dX5BXAFtaMheaSCTl+FK22xoKr8vAFcwrdf3Hx07IhkcBm/LCy0Fy9YaFIUKxflyTlJm yiPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FoNjF029; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si5703809edk.210.2019.11.08.11.24.37; Fri, 08 Nov 2019 11:25:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FoNjF029; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387583AbfKHSzb (ORCPT + 99 others); Fri, 8 Nov 2019 13:55:31 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:55470 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731795AbfKHSz3 (ORCPT ); Fri, 8 Nov 2019 13:55:29 -0500 Received: by mail-wm1-f66.google.com with SMTP id b11so7200305wmb.5 for ; Fri, 08 Nov 2019 10:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rSeEzJJFL2J46kppo+eAa64DAYEYghhg+PgDA1kJZ2g=; b=FoNjF029RF5QDxb2sTGkwafqxS7YPNOhJGn3vNt7RzmZDJi4By/FaCgouK1Hs2vi2N yCV/rw4mygjkOCRUrQclgCUnJd7eITqD/r/NGybiUNmuKS3gXnMLXPBo8O5CRzMrxjZp 9cwmybzUPhjMRGqjHvkiKogdVp5hd2XHXlEtv0w4c+Uvxac/xrFToxgkmJ9MZL0ypFrD Mhy6/Upn3gfAWw5k1jvf/4uhN4QoUrK8v5vSe9MdT0X1wn3QVXSO8HxNhX7O0ij3LZ8C XzB01wbuh+xKD9uidorsG/pt2KouHgAFqMRbWRmnY0WOUHIRCb2jHQxDqvnBn8xOjNXD h+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rSeEzJJFL2J46kppo+eAa64DAYEYghhg+PgDA1kJZ2g=; b=m2pz3m3lFTRqGR1ARM+2Nf1cr/06HVT3+m4UKOztCNW7+C8WdO1fzHycJ+U1jd+ZTB Z7KOzwKbUrM+TMlZW6iVwNGcmIS1oMVO3wlluyEhW5gLpHy9SPHICHOgExU4jSGkOZaO yPmGpX5ytnM0sq2D3SApqVbkbsESDw0+ZANareDacBLtJakswokDDfJ4BT0rsCDgKgJa Oq/yEIEcX3XUjT7IwgOIuN8g2N+iQb2NpdQikI6rlL4ZSwI45fRpnpEP+Kt835/YZ4iF XokE8FaOVvO6L+5u7h3lx9QZlESo6veogeTseNb9Ll5G+8WtuLIBKlN3bAw1kNR4jiVo IEhQ== X-Gm-Message-State: APjAAAW4Kh9QJr3in0V5/G85/d8HJWw8DsJsZRxTtw6BpVKzTtd6soqM JwCKDowpGOXeixivm/dkvcAY5y0D3bC3TC+z6Ous0whb X-Received: by 2002:a05:600c:2295:: with SMTP id 21mr9059047wmf.85.1573239326290; Fri, 08 Nov 2019 10:55:26 -0800 (PST) MIME-Version: 1.0 References: <20191107132755.8517-1-jonas@norrbonn.se> <20191107132755.8517-2-jonas@norrbonn.se> In-Reply-To: From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Fri, 8 Nov 2019 10:55:09 -0800 Message-ID: Subject: Re: [PATCH v3 1/6] rtnetlink: allow RTM_SETLINK to reference other namespaces To: Jonas Bonn Cc: nicolas.dichtel@6wind.com, linux-netdev , linux-kernel@vger.kernel.org, David Miller Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jonas, thanks for the response. On Fri, Nov 8, 2019 at 12:20 AM Jonas Bonn wrote: > > Hi Mahesh, > > On 07/11/2019 21:36, Mahesh Bandewar (=E0=A4=AE=E0=A4=B9=E0=A5=87=E0=A4= =B6 =E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4=BE=E0=A4=B0) wrote: > > On Thu, Nov 7, 2019 at 5:30 AM Jonas Bonn wrote: > >> > >> > >> + /* A hack to preserve kernel<->userspace interface. > >> + * It was previously allowed to pass the IFLA_TARGET_NETNSID > >> + * attribute as a way to _set_ the network namespace. In this > >> + * case, the device interface was assumed to be in the _curre= nt_ > >> + * namespace. > >> + * If the device cannot be found in the target namespace then = we > >> + * assume that the request is to set the device in the current > >> + * namespace and thus we attempt to find the device there. > >> + */ > > Could this bypasses the ns_capable() check? i.e. if the target is > > "foo" but your current ns is bar. The process may be "capable" is foo > > but the interface is not found in foo but present in bar and ends up > > modifying it (especially when you are not capable in bar)? > > I don't think so. There was never any capable-check for the "current" > namespace so there's no change in that regard. > not having capable-check seems wrong as we don't want random not-capable processes to alter settings. However, it may be at the API entry level, which will provide necessary protection (haven't checked!). Having said that, this could be bad for the stuff that you are implementing since I could be in "foo" and attempting to change "bar". For this I must be capable in "bar" but the top-level capable check will by default check me in "foo" as well which is not required and could potentially block me from performing legal operation in "bar". Not saying this is a problem, but without having an implementation to use this would be hard to try. You would most likely have a way to verify this, so please check it. > I do think there is an issue with this hack that I can't see any > workaround for. If the user specifies an interface (by name or index) > for another namespace that doesn't exist, there's a potential problem if > that name/index happens to exist in the "current" namespace. In that > case, one many end up inadvertently modifying the interface in the > current namespace. I don't see how to avoid that while maintaining the > backwards compatibility. > This could very well be the case always for single digit ifindex values. (We recently suffered a local scare because of something very similar). > My absolute preference would be to drop this compat-hack altogether. > iproute2 doesn't use a bare TARGET_NETNSID in this manner (for changing > namespaces) and I didn't find any other users by a quick search of other > prominent Netlink users: systemd, network-manager, connman. This > compat-hack is there for the _potential ab-user_ of the interface, not > for any known such. > what is forcing you keeping you keeping / implementing this hack? I would also prefer simple solution without creating a potential problem / vulnerability (problem: potentially modifying unintended interface, vulnerability: potentially allow changing without proper credentials; both not proven but are possibilities) down the line. One possibility is to drop the compatibility hack and keep it as a backup if something breaks / someone complains. thanks, --mahesh.. > > > >> + if (!dev && tgt_net) { > >> + net =3D sock_net(skb->sk); > >> + if (ifm->ifi_index > 0) > >> + dev =3D __dev_get_by_index(net, ifm->ifi_index= ); > >> + else if (tb[IFLA_IFNAME]) > >> + dev =3D __dev_get_by_name(net, ifname); > >> + } > > > /Jonas