From: Paolo Abeni <pabeni at redhat.com> To: mptcp at lists.01.org Subject: [MPTCP] Re: [RFC PATCH] selinux: handle MPTCP consistently with TCP Date: Tue, 08 Dec 2020 16:35:05 +0100 [thread overview] Message-ID: <08b7534580e1bdb134ba0c2816977836cd446c5d.camel@redhat.com> (raw) In-Reply-To: CAHC9VhS9xRSbHMCgDkix0fHYeO=aA_=DVyV1Xdu8qFpggws8Kg@mail.gmail.com [-- Attachment #1: Type: text/plain, Size: 1720 bytes --] Hello, I'm sorry for the latency, I'll have limited internet access till tomorrow. On Fri, 2020-12-04 at 18:22 -0500, Paul Moore wrote: > For SELinux the issue is that we need to track state in the sock > struct, via sock->sk_security, and that state needs to be initialized > and set properly. As far as I can see, for regular sockets, sk_security is allocated via: - sk_prot_alloc() -> security_sk_alloc() for client/listener sockets - sk_clone_lock() -> sock_copy() for server sockets MPTCP uses the above helpers, sk_security should be initialized properly. MPTCP goes through an additional sk_prot_alloc() for each subflow, so each of them will get it's own independent context. The subflows are not exposed to any syscall (accept()/recvmsg()/sendmsg()/poll()/...), so I guess selinux will mostly ignored them right? The kernel will pick some of them to actually send the data, and, on the receive side, will move the data from the subflows into the user- space visible mptcp socket. > Similarly with TCP request_sock structs, via > request_sock->{secid,peer_secid}. Is the MPTCP code allocating and/or > otherwise creating socks or request_socks outside of the regular TCP > code? Request sockets are easier, I guess/hope: MPTCP handles them very closely to plain TCP. > We would also be concerned about socket structs, but I'm > guessing that code reuses the TCP code based on what you've said. Only the main MPTCP 'struct socket' is exposed to the user space, and that is allocated via the usual __sys_socket() call-chain. I guess that should be fine. If you could provide some more context (what I should look after) I can dig more. Thanks! Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Abeni <pabeni@redhat.com> To: Paul Moore <paul@paul-moore.com> Cc: Florian Westphal <fw@strlen.de>, Stephen Smalley <stephen.smalley.work@gmail.com>, selinux@vger.kernel.org, mptcp@lists.01.org, linux-security-module@vger.kernel.org Subject: Re: [MPTCP] Re: [RFC PATCH] selinux: handle MPTCP consistently with TCP Date: Tue, 08 Dec 2020 16:35:05 +0100 [thread overview] Message-ID: <08b7534580e1bdb134ba0c2816977836cd446c5d.camel@redhat.com> (raw) In-Reply-To: <CAHC9VhS9xRSbHMCgDkix0fHYeO=aA_=DVyV1Xdu8qFpggws8Kg@mail.gmail.com> Hello, I'm sorry for the latency, I'll have limited internet access till tomorrow. On Fri, 2020-12-04 at 18:22 -0500, Paul Moore wrote: > For SELinux the issue is that we need to track state in the sock > struct, via sock->sk_security, and that state needs to be initialized > and set properly. As far as I can see, for regular sockets, sk_security is allocated via: - sk_prot_alloc() -> security_sk_alloc() for client/listener sockets - sk_clone_lock() -> sock_copy() for server sockets MPTCP uses the above helpers, sk_security should be initialized properly. MPTCP goes through an additional sk_prot_alloc() for each subflow, so each of them will get it's own independent context. The subflows are not exposed to any syscall (accept()/recvmsg()/sendmsg()/poll()/...), so I guess selinux will mostly ignored them right? The kernel will pick some of them to actually send the data, and, on the receive side, will move the data from the subflows into the user- space visible mptcp socket. > Similarly with TCP request_sock structs, via > request_sock->{secid,peer_secid}. Is the MPTCP code allocating and/or > otherwise creating socks or request_socks outside of the regular TCP > code? Request sockets are easier, I guess/hope: MPTCP handles them very closely to plain TCP. > We would also be concerned about socket structs, but I'm > guessing that code reuses the TCP code based on what you've said. Only the main MPTCP 'struct socket' is exposed to the user space, and that is allocated via the usual __sys_socket() call-chain. I guess that should be fine. If you could provide some more context (what I should look after) I can dig more. Thanks! Paolo
next reply other threads:[~2020-12-08 15:35 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-08 15:35 Paolo Abeni [this message] 2020-12-08 15:35 ` [MPTCP] Re: [RFC PATCH] selinux: handle MPTCP consistently with TCP Paolo Abeni -- strict thread matches above, loose matches on Subject: below -- 2020-12-10 2:43 Paul Moore 2020-12-10 2:43 ` Paul Moore 2020-12-09 10:02 Paolo Abeni 2020-12-09 10:02 ` Paolo Abeni 2020-12-08 23:35 Paul Moore 2020-12-08 23:35 ` Paul Moore 2020-12-04 23:22 Paul Moore 2020-12-04 23:22 ` Paul Moore 2020-12-04 10:04 Paolo Abeni 2020-12-04 10:04 ` Paolo Abeni 2020-12-04 2:24 Paul Moore 2020-12-04 2:24 ` Paul Moore 2020-12-03 23:54 Florian Westphal 2020-12-03 23:54 ` Florian Westphal 2020-12-03 23:30 Paul Moore 2020-12-03 23:30 ` Paul Moore 2020-12-03 17:24 Mat Martineau 2020-12-03 17:24 ` Mat Martineau 2020-12-02 11:17 Paolo Abeni 2020-12-02 11:17 ` [MPTCP] " Paolo Abeni 2020-12-02 10:31 Paolo Abeni 2020-12-02 10:31 ` Paolo Abeni
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=08b7534580e1bdb134ba0c2816977836cd446c5d.camel@redhat.com \ --to=unknown@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.