netdev - Re: [PATCH net-next] net-loopback: allow lo dev initial state to be controlled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Dec 2020 18:38:18 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Mahesh Bandewar (महेश बंडेवार) " <maheshb@...gle.com>
Cc:     nicolas.dichtel@...nd.com, David Ahern <dsahern@...il.com>,
        Ido Schimmel <idosch@...sch.org>,
        Jian Yang <jianyang.kernel@...il.com>,
        David Miller <davem@...emloft.net>,
        linux-netdev <netdev@...r.kernel.org>,
        Jian Yang <jianyang@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next] net-loopback: allow lo dev initial state to be
 controlled

On Tue, 1 Dec 2020 12:24:38 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Nov 19, 2020 at 8:56 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > Do you have more details on what the use cases are that expect no
> > networking?
> >
> > TBH I don't get the utility of this knob. If you want to write vaguely
> > portable software you have to assume the knob won't be useful, because
> > either (a) kernel may be old, or (b) you shouldn't assume to own the
> > sysctls and this is a global one (what if an application spawns that
> > expects legacy behavior?)
> >
> > And if you have to check for those two things you're gonna write more
> > code than just ifuping lo would be.
> >
> > Maybe you can shed some more light on how it makes life at Google
> > easier for you? Or someone else can enlighten me?
> >
> > I don't have much practical experience with namespaces, but the more
> > I think about it the more pointless it seems.  
> 
> Thanks for the input.
> 
> Sorry, I was on vacation and couldn't process this response earlier.
> 
> There are two things that this patch is providing and let me understand the
> objections well.
> 
> (a) Bring up lo by default
> (b) sysctl to protect the legacy behavior
> 
> Frankly we really dont have any legacy-behavior use case and one can
> bring it back to life by just doing 'ifdown lo' if necessary.

If use cases depending on legacy behavior exist we are just trading the
ifup in one case for an ifdown in another.

Unless we can dispel the notion that sand-boxing by lo down is a
legitimate use case IMO we're just adding complexity and growing
a sysctl for something that can be trivially handled from user space.

> Most of
> the use cases involve using networking anyways. My belief was that we
> need to protect legacy behavior and hence went lengths to add sysctl
> to protect it. If we are OK not to have it, I'm more than happy to
> remove the sysctl and just have the 3 line patch to bring loopback up.
> 
> If legacy-behavior is a concern (which I thought generally is), then
> either we can have the sysctl to have it around to protect it (the
> current implementation) but if we prefer to have kernel-command-line
> instead of sysctl that defaults to legacy behavior but if provided, we
> can set it UP by default during boot (or the other way around)?
> 
> My primary motive is (a) while (b) is just a side-effect which we can
> get away if deemed unnecessary.