On Thu, 8 Dec 2022, Casey Schaufler wrote:
On 12/7/2022 6:19 PM, Mat Martineau wrote:
On Wed, 7 Dec 2022, Paolo Abeni wrote:
MPTCP sockets created via accept() inherit their LSM label
from the initial request socket, which in turn get it from the
listener socket's first subflow. The latter is a kernel socket,
and get the relevant labeling at creation time.
Due to all the above even the accepted MPTCP socket get a kernel
label, causing unexpected behaviour and failure on later LSM tests.
Address the issue factoring out a socket creation helper that does
not include the post-creation LSM checks. Use such helper to create
mptcp subflow as in-kernel sockets and doing explicitly LSM validation:
vs the current user for the first subflow, as a kernel socket otherwise.
Fixes: 0c14846032f2 ("mptcp: fix security context on server socket")
Reported-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
The MPTCP content looks good to me:
Acked-by: Mat Martineau <mathew.j.martineau@xxxxxxxxxxxxxxx>
I didn't see issues with the socket.c changes but I'd like to get some
security community feedback before upstreaming - Paul or other
security reviewers, what do you think?
I haven't had the opportunity to work out what impact, if any, this will
have on Smack. I haven't seen a reproducer for the problem, is one available?
Sorry to chime in late.
Hi Casey -
There's more context in the original thread started by Ondrej, including
reproducer information:
https://lore.kernel.org/all/CAFqZXNs2LF-OoQBUiiSEyranJUXkPLcCfBkMkwFeM6qEwMKCTw@xxxxxxxxxxxxxx/
For impact on Smack, also check Paul's recent reply to this specific patch
(proposing a new LSM hook):
https://lore.kernel.org/all/CAHC9VhQzJAhNtpMnU7STEfq6QpaJo-xiie8HoHH2w3io3aXBHw@xxxxxxxxxxxxxx/
--
Mat Martineau
Intel
