From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C72BC352A1 for ; Tue, 6 Dec 2022 16:53:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235544AbiLFQxG (ORCPT ); Tue, 6 Dec 2022 11:53:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235462AbiLFQxF (ORCPT ); Tue, 6 Dec 2022 11:53:05 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1887BB46 for ; Tue, 6 Dec 2022 08:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670345522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XIpckjVarsXSQqROHjIV5YMQ3njKr27YAdfHQ1eBWXM=; b=JpPeZRVuDnCD/TTN1sDBE150dHBM7ryYDl3QVQzsuwPyRrmrouP9Z8HvCosY85/EN8DYrI udnKWwgrMxnVK3fTIqxTrgz/5jBdsxc84HQaANTmc5R3EAq9aVCaYJyKTSKqj9zI3WCDPW xN6kFzV7dts8BT7kGnx9VLCh8lLXoLU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-460-v-EVIzt0OeCXAa6qYVRIPA-1; Tue, 06 Dec 2022 11:52:00 -0500 X-MC-Unique: v-EVIzt0OeCXAa6qYVRIPA-1 Received: by mail-wm1-f70.google.com with SMTP id z15-20020a1c4c0f000000b003cf6f80007cso5869114wmf.3 for ; Tue, 06 Dec 2022 08:52:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XIpckjVarsXSQqROHjIV5YMQ3njKr27YAdfHQ1eBWXM=; b=rjCj8Jtd9SIuhLshGt/l6mFrrjipH6s/is+EFtMmyJ280gGLZvrXw19DRgQnlakxjY WMgTM5v9e5JgNJHwvJggkGltQh8stGWFyn1po23ry5U25pWk1aeR9gM0eCFkZaX5lDgK ZX21ktxh23HE53pX1eaGWw2jeY7bz+OilC4NBvCljuMA96/xDis4uOQmYITpUU33gENj j9rKF6SXPbkXwL2rX1zBgxUlltOyzLpM3nDeCEF8XXlo41kjPtgxaHBpMfty2SJ80eoL 3BJ52f0JxFdr1sMArhMXTAN3ihgviSCt6i+BxgzE4Ui5CFYjyC1zum/JrjdzPo/HC58G SUUA== X-Gm-Message-State: ANoB5pn0Wg3jcNTm44bJgqydY7BGWfjTUakFBGTHAkui95NOj/NVZCUc YzRCYR+eExNusFF5etCE+KAMQ7Ufwwpsz2IekoX79VC87t/FprZEGbiV9AeotDgcSQG9CO+SWHr PNUUmf0O4hd4kRtDWrEjCMH6H4slD7V4tMxV+ X-Received: by 2002:adf:ebc6:0:b0:241:c6d8:be83 with SMTP id v6-20020adfebc6000000b00241c6d8be83mr46196222wrn.454.1670345519816; Tue, 06 Dec 2022 08:51:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf60dqg/J7gSlr8BiWptFPCbF1mq7Dzc0r47+I6tQYq+KjcdkixAhM+jx7p9yL/Kn4RX5L/gMA== X-Received: by 2002:adf:ebc6:0:b0:241:c6d8:be83 with SMTP id v6-20020adfebc6000000b00241c6d8be83mr46196208wrn.454.1670345519570; Tue, 06 Dec 2022 08:51:59 -0800 (PST) Received: from gerbillo.redhat.com (146-241-106-100.dyn.eolo.it. [146.241.106.100]) by smtp.gmail.com with ESMTPSA id f6-20020a0560001b0600b002415dd45320sm16896783wrz.112.2022.12.06.08.51.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Dec 2022 08:51:59 -0800 (PST) Message-ID: <99550009c78de401d55356721aac56873319b5cc.camel@redhat.com> Subject: Re: Broken SELinux/LSM labeling with MPTCP and accept(2) From: Paolo Abeni To: Ondrej Mosnacek Cc: Paul Moore , SElinux list , Linux Security Module list , mptcp@lists.linux.dev, network dev , Mat Martineau , Matthieu Baerts Date: Tue, 06 Dec 2022 17:51:57 +0100 In-Reply-To: References: <108a1c80eed41516f85ebb264d0f46f95e86f754.camel@redhat.com> <48dd1e9b21597c46e4767290e5892c01850a45ff.camel@redhat.com> <50e7ea22119c3afcb4be5a4b6ad9747465693d10.camel@redhat.com> User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: On Tue, 2022-12-06 at 15:43 +0100, Ondrej Mosnacek wrote: > On Mon, Dec 5, 2022 at 9:58 PM Paolo Abeni wrote: > > > > On Fri, 2022-12-02 at 15:16 -0500, Paul Moore wrote: > [...] > > > What if we added a new LSM call in mptcp_subflow_create_socket(), just > > > after the sock_create_kern() call? > > > > That should work, I think. I would like to propose a (last) attempt > > that will not need an additional selinux hook - to try to minimize the > > required changes and avoid unnecessary addional work for current and > > future LSM mainteniance and creation. > > > > I tested the following patch and passes the reproducer (and mptcp self- > > tests). Basically it introduces and uses a sock_create_nosec variant, > > to allow mptcp_subflow_create_socket() calling > > security_socket_post_create() with the corrct arguments. WDYT? > > This seems like a step in the right direction, but I wonder if we > shouldn't solve the current overloading of the "kern" flag more > explicitly - i.e. split it into two flags: one to indicate that the > socket will only be used internally by the kernel ("internal") and > another one to indicate if it should be labeled according to the > current task or as a kernel-created socket ("kern"?). Technically, > each combination could have a valid use case: > - !internal && !kern -> a regular userspace-created socket, > - !internal && kern -> a socket that is exposed to userspace, but > created by the kernel outside of a syscall (e.g. some global socket > created during initcall phase and later returned to userspace via an > ioctl or something), > - internal && !kern -> our MPTCP case, where the socket itself is > internal, but the label is still important so it can be passed onto > its accept-offspring (which may no longer be internal), > - internal && kern -> a completely kernel-internal socket. I would say perfect is the enemy of good ;) it would be nice to have a fix sometime soon, and we can improve as needed. > Another concern I have about this approach is whether it is possible > (in some more advanced scenario) for mptcp_subflow_create_socket() to > be called in the context of a different task than the one > creating/handling the main socket. Because then a potential socket > accepted from the new subflow socket would end up with an unexpected > (and probably semantically wrong) label. Glancing over the call tree, > it seems it can be called via some netlink commands - presumably > intended to be used by mptcpd? Yes, the above can happen, but I think it does not have LSM-related implications, as subflows created in the above scenario can be MP_JOIN only - that is, will never be even indirectly exposed to user-space. Cheers, Paolo