All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: network dev <netdev@vger.kernel.org>,
	"linux-sctp @ vger . kernel . org" <linux-sctp@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Linux Security Module list 
	<linux-security-module@vger.kernel.org>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH net] sctp: use the correct skb for security_sctp_assoc_request
Date: Wed, 6 Apr 2022 11:11:34 -0400	[thread overview]
Message-ID: <CADvbK_drixdD3FBiVH+3V=wpN4QjrFZB+oWrGf-XjYKKGNJL0Q@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNvk0i+WC8O=BhETCPYgaKm1zE29JQHfMety8CA7EKhDtg@mail.gmail.com>

On Wed, Apr 6, 2022 at 11:04 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Wed, Apr 6, 2022 at 4:21 PM Xin Long <lucien.xin@gmail.com> wrote:
> > On Wed, Apr 6, 2022 at 9:34 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > On Tue, Apr 5, 2022 at 1:58 PM Xin Long <lucien.xin@gmail.com> wrote:
> > > > On Mon, Apr 4, 2022 at 6:15 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > >
> > > > > Adding LSM and SELinux lists to CC for awareness; the original patch
> > > > > is available at:
> > > > > https://lore.kernel.org/netdev/a77a584b3ce9761eb5dda5828192e1cab94571f0.1649037151.git.lucien.xin@gmail.com/T/
> > > > > https://patchwork.kernel.org/project/netdevbpf/patch/a77a584b3ce9761eb5dda5828192e1cab94571f0.1649037151.git.lucien.xin@gmail.com/
> > > > >
> > > > > On Mon, Apr 4, 2022 at 3:53 AM Xin Long <lucien.xin@gmail.com> wrote:
> > > > > >
> > > > > > Yi Chen reported an unexpected sctp connection abort, and it occurred when
> > > > > > COOKIE_ECHO is bundled with DATA Fragment by SCTP HW GSO. As the IP header
> > > > > > is included in chunk->head_skb instead of chunk->skb, it failed to check
> > > > > > IP header version in security_sctp_assoc_request().
> > > > > >
> > > > > > According to Ondrej, SELinux only looks at IP header (address and IPsec
> > > > > > options) and XFRM state data, and these are all included in head_skb for
> > > > > > SCTP HW GSO packets. So fix it by using head_skb when calling
> > > > > > security_sctp_assoc_request() in processing COOKIE_ECHO.
> > > > >
> > > > > The logic looks good to me, but I still have one unanswered concern.
> > > > > The head_skb member of struct sctp_chunk is defined inside a union:
> > > > >
> > > > > struct sctp_chunk {
> > > > >         [...]
> > > > >         union {
> > > > >                 /* In case of GSO packets, this will store the head one */
> > > > >                 struct sk_buff *head_skb;
> > > > >                 /* In case of auth enabled, this will point to the shkey */
> > > > >                 struct sctp_shared_key *shkey;
> > > > >         };
> > > > >         [...]
> > > > > };
> > > > >
> > > > > What guarantees that this chunk doesn't have "auth enabled" and the
> > > > > head_skb pointer isn't actually a non-NULL shkey pointer? Maybe it's
> > > > > obvious to a Linux SCTP expert, but at least for me as an outsider it
> > > > > isn't - that's usually a good hint that there should be a code comment
> > > > > explaining it.
> > > > Hi Ondrej,
> > > >
> > > > shkey is for tx skbs only, while head_skb is for skbs on rx path.
> > >
> > > That makes sense, thanks. I would still be happier if this was
> > > documented, but the comment would best fit in the struct sctp_chunk
> > > definition and that wouldn't fit in this patch...
> > >
> > > Actually I have one more question - what about the
> > > security_sctp_assoc_established() call in sctp_sf_do_5_1E_ca()? Is
> > > COOKIE ACK guaranteed to be never bundled?
> > COOKIE ACK could also be bundled with DATA.
> > I didn't change it as it would not break SCTP.
> > (security_inet_conn_established() returns void)
> > But I don't mind changing it if you think it's necessary.
>
> security_inet_conn_established? Are you looking at an old version of
> the code, perhaps? In mainline, sctp_sf_do_5_1E_ca() now calls the new
> security_sctp_assoc_established() hook, which may return an error. But
> even if it didn't, I believe we want to make sure that an skb with
> valid inet headers and XFRM state is passed to the hooks as SELinux
> relies on these to correctly process the SCTP association.
Sorry, I was looking at the old one.
OK, I will post v2 with the fix in sctp_sf_do_5_1E_ca().

Thanks for reviewing.

>
> --
> Ondrej Mosnacek
> Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
>

      reply	other threads:[~2022-04-06 17:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-04  1:52 [PATCH net] sctp: use the correct skb for security_sctp_assoc_request Xin Long
2022-04-04 10:15 ` Ondrej Mosnacek
2022-04-05 11:58   ` Xin Long
2022-04-06 13:33     ` Ondrej Mosnacek
2022-04-06 14:21       ` Xin Long
2022-04-06 15:04         ` Ondrej Mosnacek
2022-04-06 15:11           ` Xin Long [this message]

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='CADvbK_drixdD3FBiVH+3V=wpN4QjrFZB+oWrGf-XjYKKGNJL0Q@mail.gmail.com' \
    --to=lucien.xin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=omosnace@redhat.com \
    --cc=selinux@vger.kernel.org \
    /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: link
Be 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.