netdev - Re: [net-next v2] 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: <20201030082248.033df7ef@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Fri, 30 Oct 2020 08:22:48 -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-next v2] tipc: add stricter control of reserved service
 types

On Thu, 29 Oct 2020 21:29:38 -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.
> 
> Acked-by: Yung Xue <ying.xue@...driver.com>
> 
> ---

Please be careful with the separator, git am cuts off the rest of the
message including your sign-off. 

> v2: Added warning printout when a user is blocked from binding,
>     as suggested by Jakub Kicinski
> 
> Signed-off-by: Jon Maloy <jmaloy@...hat.com>

Fixed up the message, and applied. Thanks!