[PATCH mptcp-net] mptcp: fix LSM labeling for passive msk

[Mat Martineau]

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 at redhat.com>
>>> Signed-off-by: Paolo Abeni <pabeni at redhat.com>
>>
>> The MPTCP content looks good to me:
>>
>> Acked-by: Mat Martineau <mathew.j.martineau at linux.intel.com>
>>
>>
>> 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@mail.gmail.com/

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@mail.gmail.com/

--
Mat Martineau
Intel