netdev - Re: [net] tipc: add stricter control of reserved service types

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] [day] [month] [year] [list]

Message-ID: <20201029151110.41fae663@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Thu, 29 Oct 2020 15:11:10 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     jmaloy@...hat.com
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        tipc-discussion@...ts.sourceforge.net,
        tung.q.nguyen@...tech.com.au, hoang.h.le@...tech.com.au,
        tuong.t.lien@...tech.com.au, maloy@...jonn.com, xinl@...hat.com,
        ying.xue@...driver.com, parthasarathy.bhuvaragan@...il.com
Subject: Re: [net] tipc: add stricter control of reserved service types

On Wed, 28 Oct 2020 09:19:12 -0400 jmaloy@...hat.com wrote:
> From: Jon Maloy <jmaloy@...hat.com>
> 
> TIPC reserves 64 service types for current and future internal use.
> Therefore, the bind() function is meant to block regular user sockets
> from being bound to these values, while it should let through such
> bindings from internal users.
> 
> However, since we at the design moment saw no way to distinguish
> between regular and internal users the filter function ended up
> with allowing all bindings of the reserved types which were really
> in use ([0,1]), and block all the rest ([2,63]).
> 
> This is risky, since a regular user may bind to the service type
> representing the topology server (TIPC_TOP_SRV == 1) or the one used
> for indicating neighboring node status (TIPC_CFG_SRV == 0), and wreak
> havoc for users of those services, i.e., most users.
> 
> The reality is however that TIPC_CFG_SRV never is bound through the
> bind() function, since it doesn't represent a regular socket, and
> TIPC_TOP_SRV can also be made to bypass the checks in tipc_bind()
> by introducing a different entry function, tipc_sk_bind().
> 
> It should be noted that although this is a change of the API semantics,
> there is no risk we will break any currently working applications by
> doing this. Any application trying to bind to the values in question
> would be badly broken from the outset, so there is no chance we would
> find any such applications in real-world production systems.

You say above that it would wreak havoc for most users, not all :)

I'd be more comfortable applying this to net-next, does that work for
you? 

Also perhaps we could add a pr_warn_once() if an application tried
using the reserved values, to help identify this change right away.

> Acked-by: Yung Xue <ying.xue@...driver.com>
> Signed-off-by: Jon Maloy <jmaloy@...hat.com>