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]
Message-ID: <CAHo-OoycbdoMO7aRW23-0B+Ev7Ow=YXy3uHmrx7FOKf2PXc4hA@mail.gmail.com>
Date:   Fri, 8 Jun 2018 03:07:30 -0700
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Andrei Vagin <avagin@...tuozzo.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Linux NetDev <netdev@...r.kernel.org>
Subject: Re: net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets

I think we probably need to make sk->sk_reuse back into a boolean.
(ie. eliminate SK_FORCE_REUSE)

Then add a new tcp/udp sk->ignore_bind_conflicts boolean setting...
(ie. not just for tcp, but sol_socket)  [or perhaps SO_REPAIR,
sk->repair or something]

What I'm not certain of is exactly what sorts of conflicts it should ignore...
all?  probably not, still seems utterly wrong to allow creation of 2 connected
tcp sockets with identical 5-tuples.

Would it only ignore conflicts against other i_b_c sockets?
ie. set it on all sockets as we're repairing, then clear it on them
all once we're done?

and ignore all the fast caching when checking conflicts for an i_b_c socket?

For CRIU is it safe to assume we're restoring an entire namespace into
a new namespace?

Could we perhaps instead allow a new namespace to ignore bind conflicts until
we flip it into enforcing mode?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ